Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/1all-charters.txt

Text File | 1993-03-03 | 257KB | 6,635 lines

Internet Message Extensions (822ext)

Charter

Chair(s):
     Gregory Vaudreuil  <[e-mail]>

Applications Area Director(s)
     Russ Hobby  <[e-mail]>
     Erik Huizer  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           cnri.reston.va.us:~/ietf.mail.archives/822ext/*

Description of Working Group:

This Working Group was chartered to extend the RFC 822 Message format to
facilitate multi-media mail and alternate character sets.  RFCs 1341
and RFC 1342 document the Multi-Media Extensions for Internet Mail.

The Working Group will work to progress MIME to Draft Standard status
and provide a forum for the review of standards track content-type
specifications and the review of character set extensions to MIME.

Goals and Milestones:

     Done Review the Charter, and refine the Group's focus. Decide whether this
          is a worthwhile effort.

     Done Discuss, debate, and choose a framework for the solution.
          Assign writing assignments, and identify issues to be resolved.

     Done Review exiting writing, resolve outstanding issues, identify
          new work, and work toward a complete document.

     Done Post a first Internet Draft.

     Done Review and finalize the draft document.

     Done Submit the document as a Proposed Standard.

     Done Post an Internet Draft for the use of Japanese Characters for
          Internet Mail.

     Done Post a revised version of the MIME document as an Internet Draft.

   Mar 93 Submit the revised MIME document to the IESG for consideration as a
          Draft Standard.

   Mar 93 Submit the Japanese Character set specification as an Informational
          document.

Internet Accounting (acct)

Charter

Chair(s):
     Cyndi Mills  <[e-mail]>
     Gregory Ruth  <[e-mail]>

Network Management Area Director(s)
     J.R. Davin  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The Internet Accounting Working Group has the goal of producing
standards for the generation of accounting data within the Internet
that can be used to support a wide range of management and cost
allocation policies.  The introduction of a common set of tools and
interpretations should ease the implementation of organizational
policies for Internet components and make them more equitable in a
multi-vendor environment.

In the following accounting model, this Working Group is primarily
concerned with defining standards for the Meter function and
recommending protocols for the Collector function.  Individual
accounting applications (billing applications) and organizational
policies will not be addressed, although examples should be provided.

Meter $<$--$>$ Collector $<$--$>$ Application $<$--$>$ Policy

First, examine a wide range of existing and hypothetical policies to
understand what set of information is required to satisfy usage
reporting requirements.  Next, evaluate existing mechanisms to generate
this information and define the specifications of each accounting
parameter to be generated.  Determine the requirements for local storage
and how parameters may be aggregated.  Recommend a data collection
protocol and internal formats for processing by accounting applications.

This will result in an Internet-Draft suitable for experimental
verification and implementation.

In parallel with the definition of the draft standard, develop a suite
of test scenarios to verify the model.  Identify candidates for
prototyping and implementation.

\newpage

Goals and Milestones:

     Done Policy models examined.

     Done Internet Accounting Background Working Draft written.

     Done Collection Protocols Working Papers written.

     Done Internet Accounting Background final draft submitted to the IESG for
          consideration as an Informational RFC.

     Done Collection protocol recommendation.

     Done Architecture submission as Internet-Draft.

     Done Post the Accounting Meter MIB as an Internet-Draft.

   Jan 93 Architecture document submitted to the IESG for consideration as a
          Proposed Standard.

   Jan 93 Submit the Accounting Meter MIB to the IESG for consideration as a
          Proposed Standard.

Alert Management (alertman)

Charter

Chair(s):
     Louis Steinberg  <[e-mail]>

Network Management Area Director(s)
     J.R. Davin  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Status: concluded

Description of Working Group:

The Alert Management Working Group is chartered with defining and
developing techniques to manage the flow of asynchronously generated
information between a manager (NOC) and its remote managed entities.
The output of this group should be fully compatible with the letter and
spirit of SNMP (RFC 1067) and CMOT (RFC 1095).


Goals and Milestones:

     Done  Develop, implement, and test protocols and mechanisms to prevent a
          managed entity from burdening a manager with an unreasonable amount
          of unexpected network management information. This will focus on
          controlling mechanisms once the information has been generated by a
          remote device.

   May 90 Develop, implement, and test mechanisms to prevent a managed entity
          from generating locally an excess of alerts to be controlled.  This
          system will focus on how a protocol or MIB object might internally
          prevent itself from generating an unreasonable amount of information.

     Done Write an RFC detailing the above, including examples of its
          conforment use with both SNMP traps and CMOT events.

   Dec 90 Write an RFC detailing the above.  Since the implementation of these
          mechanisms is protocol dependent, the goal of this RFC would be to
          offer guidance only.  It would request a status of ``optional''.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  RFC  Stat Published    Title
------- -- ---------- -----------------------------------------
RFC1224 E    May 91     Techniques for Managing Asynchronously Generated Alerts
IP over AppleTalk (appleip)

Charter

Chair(s):
     John Veizades  <[e-mail]>

Internet Area Director(s)
     Philip Almquist  <[e-mail]>
     Stev Knowles  <[e-mail]>
     Dave Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The Macintosh Working Group is chartered to facilitate the connection
of Apple Macintoshes to IP internets and to address the issues of
distributing AppleTalk services in an IP internet.


Goals and Milestones:

     Done Post an Internet-Draft the current set of protocols used to connect
          Macintoshes to IP internets.

     Done Submit the AppleTalk MIB to the IESG for consideration as a Proposed
          Standard.

   Jan 93 Submit the IP over Appletalk document to the IESG for consideration
          as a Proposed Standard.

IP over Asynchronous Transfer Mode (atm)

Charter

Chair(s):
     Robert Hinden  <[e-mail]>

Internet Area Director(s)
     Philip Almquist  <[e-mail]>
     Stev Knowles  <[e-mail]>
     Dave Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           Send message to [e-mail]

Description of Working Group:

The IP over ATM Working Group will focus on the issues involved in
running internetworking protocols over Asynchronous Transfer Mode
(ATM) networks.  The final goal for the Working Group is to produce
standards for the TCP/IP protocol suite and recommendations which
could be used by other internetworking protocol standards (e.g., ISO
CLNP and IEEE 802.2 Bridging).

The Working Group will initially develop experimental protocols for
encapsulation, multicasting, addressing, address resolution, call set
up, and network management to allow the operation of internetwork
protocols over an ATM network.  The Working Group may later submit
these protocols for standardization.

The Working Group will not develop physical layer standards for ATM.
These are well covered in other standard groups and do not need to be
addressed in this Group.

The Working Group will develop models of ATM internetworking
architectures.  This will be used to guide the development of specific IP
over ATM protocols.

The Working Group will also develop and maintain a list of technical
unknowns that relate to internetworking over ATM.  These will be used
to direct future work of the Working Group or be submitted to other
standard or research groups as appropriate.

The Working Group will coordinate its work with other relevant
standards bodies (e.g., ANSI T1S1.5) to insure that it does not
duplicate their work and that its work meshes well with other
activities in this area.  The Working Group will select among ATM
protocol options (e.g., selection of an adaptation layer protocol) and
make recommendations to the ATM standards bodies regarding the
requirements for internetworking over ATM where the current ATM
standards do not meet the needs of internetworking.


Goals and Milestones:

     Done First Meeting.  Establish detailed goals and milestones for Working
          Group.

     Done Post an Internet-Draft for a mechanism for IP over ATM.
          (Multi-Protocol Interconnect over ATM AAL5)

     Done Submit the Multi-Protocol Interconnect over ATM AAL5 to the IESG as a
          Proposed Standard.

   Mar 93 Post Internet-Draft for ``Internet Requirements for ATM Signaling''.

   Jul 93 Submit ``Internet Requirements for ATM Signaling'' to the IESG for
          consideration as an Informational Document.

Audio/Video Transport (avt)

Charter

Chair(s):
     Stephen Casner  <[e-mail]>

Transport and Services Area Director(s)
     Dave Borman  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           nic.es.net:~/ietf/rem-conf/av-transport-archive

Description of Working Group:

     The Audio/Video Transport Working Group was formed to specify experimental
     protocols for real-time transmission of audio and video over UDP
     and IP multicast.  The focus of this Group is near-term and its
     purpose is to integrate and coordinate the current AV transport
     efforts of existing research activities.  No standards-track
     protocols are expected to be produced because UDP transmission of
     audio and video is only sufficient for small-scale experiments
     over fast portions of the Internet.  However, the transport
     protocols produced by this Working Group should be useful on a larger scale
     in the future in conjunction with additional protocols to access
     network-level resource management mechanisms.  Those mechanisms,
     research efforts now, will provide low-delay service and guard
     against unfair consumption of bandwidth by audio/video traffic.

     Similarly, initial experiments can work without any connection
     establishment procedure so long as a priori agreements on port
     numbers and coding types have been made.  To go beyond that, we
     will need to address simple control protocols as well.  Since IP
     multicast traffic may be received by anyone, the control
     protocols must handle authentication and key exchange so that the
     audio/video data can be encrypted.  More sophisticated connection
     management is also the subject of current research.  It is
     expected that standards-track protocols integrating transport,
     resource management, and connection management will be the result
     of later working group efforts.

     The AVT Working Group may design independent protocols specific to each
     medium, or a common, lightweight, real-time transport protocol
     may be extracted.  Sequencing of packets and synchronization
     among streams are important functions, so one issue is the form
     of timestamps and/or sequence numbers to be used.  The Working Group will
     not focus on compression or coding algorithms which are domain of
     higher layers.

Goals and Milestones:

     Done Define the scope of the Working Group, and who might contribute.  Our
          first step will be to solicit contributions of potential protocols
          from projects that have already developed packet audio and video.
          From these contributions we will distill the appropriate protocol
          features.

     Done Conduct a teleconference Working Group meeting using a combination of
          packet audio and telephone.  The topic will be a discussion of issues
          to be resolved in the process of synthesizing a new protocol.

     Done Review contributions of existing protocols, and discuss which
          features should be included and tradeoffs of different methods.  Make
          writing assignments for first-draft documents.

     Done Post an Internet-Draft of the lightweight audio/video transport
          protocol.

   Mar 93 Submit to the IESG the Audio/Video Transport protocol for publication
          as an Experimental Protocol.

Border Gateway Protocol (bgp)

Charter

Chair(s):
     Yakov Rekhter  <[e-mail]>

Routing Area Director(s)
     Bob Hinden  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

Develop the BGP protocol and BGP technical usage within the Internet,
continuing the current work of the Interconnectivity Working Group in
this regard.


Goals and Milestones:

  Ongoing Coordinate the deployment of BGP in conformance with the BGP usage
          document in a manner that promotes sound engineering and an open
          competitive environment.  Take into account the interests of the
          various backbone and mid-level networks, the various vendors, and the
          user community.

     Done Complete development of Version 2 of the Border Gateway Protocol
          (BGP).

     Done Develop a mature BGP technical usage document that  allows us to
          build Inter-AS routing structures using the BGP protocol.

     Done Develop a MIB for BGP Version 3.

     Done Work with the Security Area to enhance the provision for security in
          BGP.

     Done Develop a BGP usage document describing how BGP can be used as part
          of a network monitoring strategy.

     Done Post an Internet-Draft specifying multicast extensions to BGP.

     Done Post the specfication of BGP 4 as an Internet-Draft.

     Done Post an Internet-Draft specifying a MIB for BGP Version 4.

   Jan 93 Submit the multicast extensions to BGP to the IESG as a Proposed
          Standard.

   Jan 93 Submit the specification for BGP Version 4 to the IESG for
          consideration as a Proposed Standard.

   Jan 93 Submit the BGP Version 4 MIB to the IESG for consideration as a
          Proposed Standard.

BGP Deployment and Application (bgpdepl)

Charter

Chair(s):
     Jessica Yu  <[e-mail]>

Operational Requirements Area Director(s)
     Phill Gross  <[e-mail]>
     Bernard Stockman  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           merit.edu:~/pub/bgpd-archive

Description of Working Group:

The major purpose of this Group is to coordinate BGP deployment and
application in the current Internet.

It intends to create a forum for BGP users to share BGP deployment
experiences and also provide a channel for users to communicate with
router vendors who implemented or who are implementing BGP.  It also intends
to discuss BGP policy application and coordinate policy implementation
in the current internet routing environment which includes defining the
usage of policy, defining a mechanism to share policy information, etc.


Goals and Milestones:

  Ongoing Facilitate the deployment of BGP as widely as possible.

          Define the issues and the needs of policy routing in the current
          Internet architecture.  Discuss how BGP policy routing capability
          applies to Internet policy routing needs.  A document may be
          generated on this topic.

   Dec 92 Post as an Internet-Draft, a report of BGP deployment status.

   Mar 93 Post an Internet-Draft, defining a mechanism to share policy
          information between Administrative Domains.

Benchmarking Methodology (bmwg)

Charter

Chair(s):
     Scott Bradner  <[e-mail]>

Operational Requirements Area Director(s)
     Phill Gross  <[e-mail]>
     Bernard Stockman  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The major goal of the Benchmarking Methodology Working Group is to make a
series of recommendations concerning the measurement of the performance
characteristics of different classes of network equipment and software
services.

Each recommendation will describe the class of equipment or service,
discuss the performance characteristics that are pertinent to that
class, specify a suite of performance benchmarks that test the described
characteristics, as well as specify the requirements for common
reporting of benchmark results.

Classes of network equipment can be broken down into two broad
categories.  The first deals with stand-alone network devices such as
routers, bridges, repeaters, and LAN wiring concentrators.  The second
category includes host dependent equipment and services, such as network
interfaces or TCP/IP implementations.

Once benchmarking methodologies for stand-alone devices have matured
sufficiently, the Group plans to focus on methodologies for testing
system-wide performance, including issues such as the responsiveness of
routing algorithms to topology changes.

Goals and Milestones:

          Once the community has had time to comment on the definitions
          of devices and performance criteria, a second document will be
          issued.  This document will make specific recommendations regarding
          the suite of benchmark performance tests for each of the defined
          classes of network devices.

     Done The document will also define various classes of stand-alone
          network devices
          such as repeaters, bridges, routers, and LAN wiring concentrators
          as well as detail the relative importance of various  performance
          criteria within each class.

     Done Issue a document that provides a common set of definitions for
          performance criteria, such as latency and throughput.

Bridge MIB (bridge)

Charter

Chair(s):
     Fred Baker  <[e-mail]>

Network Management Area Director(s)
     J.R. Davin  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The Bridge MIB Working Group is chartered to define a set of managed
objects that instrument devices that conform to the IEEE 802.1
standard for MAC-layer bridges.

This set of objects should be largely compliant with (and even draw
from) IEEE 802.1(b), although there is no requirement that any
specific object be present or absent.

The MIB object definitions produced will be for use by SNMP and will
be consistent with other SNMP objects, standards, and conventions.



Goals and Milestones:

     Done Publish initial proposal.

     Done Submit an Internet-Draft.

     Done Submit draft for RFC publication.

   Mar 93 Publish a draft revision to RFC 1286 that reflects implementation
          experience and the result of alignments with IEEE work as an
          Internet-Draft.

   Mar 93 Publish a draft SNMP MIB that instruments functions specific to
          source routed bridges as an Internet-Draft.

   Apr 93 Submit a draft MIB for source routing bridge functions to the IESG
          for consideration as a Proposed Standard.

Common Authentication Technology (cat)

Charter

Chair(s):
     John Linn  <[e-mail]>

Security Area Director(s)
     Steve Crocker  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           bitsy.mit.edu:~/cat-ietf/archive

Description of Working Group:

The goal of the Common Authentication Technology Working Group is to
provide strong authentication to a variety of protocol callers in a
manner which insulates those callers from the specifics of underlying
security mechanisms.  By separating security implementation tasks from
the tasks of integrating security data elements into caller protocols,
those tasks can be partitioned and performed separately by
implementors with different areas of expertise.  This provides
leverage for the IETF community's security-oriented resources, and
allows protocol implementors to focus on the functions their protocols
are designed to provide rather than on characteristics of security
mechanisms.  CAT seeks to encourage uniformity and modularity in
security approaches, supporting the use of common techniques and
accommodating evolution of underlying technologies.

In support of these goals, the Working Group will pursue several
interrelated tasks.  We will work towards agreement on a common
service interface allowing callers to invoke security services, and
towards agreement on a common authentication token format,
incorporating means to identify the mechanism type in conjunction with
which authentication data elements should be interpreted.  The CAT
Working Group will also work towards agreements on suitable underlying
mechanisms to implement security functions; two candidate
architectures (Kerberos V5, based on secret-key technology and
contributed by MIT, and X.509-based public-key Distributed
Authentication Services being prepared for contribution by DEC) are
under current consideration.  The CAT Working Group will consult with
other IETF working groups responsible for candidate caller protocols,
pursuing and supporting design refinements as appropriate.


Goals and Milestones:

     Done Progress Internet-Draft and RFC publication of mechanism-level
          documents to support independent, interoperable implementations
          of CAT-supporting mechanisms.

     Done Preliminary BOF session at IETF meeting, discussions with Telnet
          and Network Printing Working Groups.

     Done Distribute Generic Security Service Application Program
          Interface (GSS-API) documentation through Internet-Draft process.

     Done First IETF meeting as full Working Group: review Charter distribute
          documents, and status of related implementation, integration, and
          consulting liaison activities. Schedule follow-on tasks, including
          documentation plan for specific CAT-supporting security mechanisms.

   Oct 91 Update mechanism-independent Internet-Drafts in response to issues
          raised, distribute additional mechanism-specific documentation
          including Distributed Authentication Services architectural
          description and terms/conditions for use of the technology documented
          therein.

   Nov 91 Second IETF meeting:  Review distributed documents and status of
          related activities, continue consulting liaisons.   Discuss features
          and characteristics of underlying mechanisms. Define scope and
          schedule for follow-on work.

   Dec 91 Submit service interface specification to to the IESG for
          consideration as a Proposed Standard.

Character MIB (charmib)

Charter

Chair(s):
     Bob Stewart  <[e-mail]>

Network Management Area Director(s)
     J.R. Davin  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Status: concluded

Description of Working Group:

The Character MIB Working Group is chartered to define a
MIB for Character Stream Ports that attach to such
devices as terminals and printers.

The Working Group must first decide what it covers and what
terminology to use.  The initial thought was to handle terminals for
terminal servers.  This directly generalizes to terminals on any host.
From there, it is a relatively close step to include printers, both
serial and parallel.  It also seems reasonable to go beyond ASCII
terminals and include others, such as 3270.  All of this results in
the suggestion that the topic is Character Stream Ports.

An important model to define is how character ports relate to
network interfaces.  Some (a minority) terminal ports can easily
become network interfaces by running SLIP, and may slip between those
states.

Given the basic models, the Group must select a set of common
objects of interest and use to a network manager responsible for
character devices.

Since the goal is an experimental MIB, it may be possible to agree
on a document in 3 to 9 months.  Most of the Group's business can be
conducted over the Internet through email.


Goals and Milestones:

     Done Mailing list discussion of Charter and collection of concerns.

     Done Discussion and final approval of Charter; discussion on models and
          terminology.  Make writing assignments.

     Done First draft document, discussion, additional drafts, special meeting?

     Done Review latest draft and if OK, give to IESG for publication as RFC.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  RFC  Stat Published    Title
------- -- ---------- -----------------------------------------
RFC1316 PS   Apr 92     Definitions of Managed Objects for Character Stream
                        Devices

RFC1317 PS   Apr 92     Definitions of Managed Objects for RS-232-like Hardware
                        Devices

RFC1318 PS   Apr 92     Definitions of Managed Objects for
                        Parallel-printer-like Hardware Devices
Chassis MIB (chassis)

Charter

Chair(s):
     Bob Stewart  <[e-mail]>
     Jeffrey Case  <[e-mail]>

Network Management Area Director(s)
     J.R. Davin  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

This Working Group will produce a document describing MIB objects for
use in a ``chassis'' --- which is a collection of traditionally
discrete network devices packaged in a single cabinet and power
supply.  A chassis may comprise, for example, combinations of layer 1
repeater elements, MAC layer bridges, or internetwork layer routers.

The Working Group is chartered to produce up to three distinct
documents that define extensions to the SNMP MIB:

(1) The Working Group is chartered to define MIB objects that represent
the mapping of the logical functions of traditional network devices
onto particular, physical hardware resources within the chassis.  These
MIB definitions will not address any aspects of the network functions
comprised by a chassis box that are shared with an analogous collection
of discrete network devices.

(2) The Working Group is chartered, at its option, to define MIB
objects that instrument the operational state of a power supply element
in a chassis.

(3) The Working Group is chartered, at its option, to define MIB
objects that represent aggregated information about collections of
network devices (e.g., aggregate information about devices attached to
a particular LAN), provided that this MIB specification is not specific
to chassis implementations of such networks and is also readily
implementable for analogous collections of discrete network devices.

The MIB object definitions produced will be for use by SNMP and will be
consistent with existing SNMP standards and framework.

Although the Working Group may choose to solicit input or expertise
from other relevant standards bodies, no extant standards efforts or
authorities are known with which alignment of this work is required.

Because the structure of chassis implementations varies widely, the
Working Group shall take special care that its definitions reflect a
generic and consistent architectural model of chassis management rather
than the structure of particular chassis implementations.

Should the Working Group elect to define objects representing
aggregated information about collections of network devices, those
efforts will not compromise the operational robustness of the SNMP that
depends on its realization of management system function as closely as
possible to centers of responsible authority.


Goals and Milestones:

     Done Discuss the Charter and define the scope of the Working Group.  In
          particular, review all contributed MIBs and agreement on plan for
          producing baseline document(s).

     Done Post the first draft of the Chassis MIB specification as an
          Internet-Draft.

   Jan 93 Submit the Chassis MIB to the IESG as a Proposed Standard.

Distributed Scheduling Protocol (chronos)

Charter

Chair(s):
     Paul Linder  <[e-mail]>

Applications Area Director(s)
     Russ Hobby  <[e-mail]>
     Erik Huizer  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           /pub/chronos @boombox.micro.umn.edu

Status: concluded

Description of Working Group:


The Chronos protocol Working Group is chartered to define a
protocol for the management of calendars, appointments and schedules
over the Internet.  In defining this protocol, several questions must
be addressed.  The role of the calendar administrator must be defined.
Differing levels of security need to be specified to allow maximum
functionality yet still allow privacy and flexibility.  The scope of
the protocol should also be evaluated; how much burden should we put
on the server, on the client?  Additionally the behavior of multiple
chronos servers must be analyzed.

This protocol should be able to be developed and stabilized
within 6-8 months, since there is already a draft specification to work
from.  The process is subject to extension if many new features are
added, or more revision is needed.



Goals and Milestones:

   Jan 91  Review first draft document, determine necessary
          revisions.  Follow up discussion will occur on mailing list.
          Prototype implementations.

   Feb 91 Make document an Internet Draft.  Continue revisions
          based on comments received over e-mail.

   Mar 91 Spring IETF meeting.   Review final draft and if OK, give
          to IESG for publication as RFC.  Begin implementations.

   Jul 91 Revise document based on implementations. Ask IESG to make the
          revision a Draft Standard.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  None to date.
Connection IP (cip)

Charter

Chair(s):
     Claudio Topolcic  <[e-mail]>

Internet Area Director(s)
     Philip Almquist  <[e-mail]>
     Stev Knowles  <[e-mail]>
     Dave Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Status: concluded

Description of Working Group:

This Working Group is looking at issues involved in
connection-oriented (or stream- or flow-oriented) internet level
protocols.  The long-term intent is to identify the issues involved,
to understand them, to identify algorithms that address them, and to
produce a specification for a protocol that incorporates what the
Working Group has learned.  To achieve this goal, the Group is
defining a two year collaborative research effort based on a common
hardware and software base.  This will include implementing different
algorithms that address the issues involved and performing experiments
to compare them.  On a shorter time-line, ST is a stream-oriented
protocol that is currently in use in the Internet.  A short-term goal
of this Working Group is to define a new specification for ST, called
ST-2, inviting participation by any interested people.  MCHIP and the
Flow Protocol have also been discussed because they include relevant
ideas.

Goals and Milestones:

     Done Define common hardware and software platform.

     Done Produce a new specification of ST.

     Done Implement hardware and software platform.

   May 91 Implement experimental modules and perform experiments.

   May 92 Produce a specification of a next generation connection oriented
          protocol.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  RFC  Stat Published    Title
------- -- ---------- -----------------------------------------
RFC1190 E    Oct 90     Experimental Internet Stream Protocol, Version 2
                        (ST-II)
Commercial Internet Protocol Security Option (cipso)

Charter

Chair(s):
     Ron Sharp  <[e-mail]>

Security Area Director(s)
     Steve Crocker  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           [e-mail]

Description of Working Group:

The Commercial Internet Protocol Security Option Working Group is
chartered to define an IP security option that can be used to pass security
information within and between security domains.  This new security option
will be modular in design to provide developers with a single software
environment which can support multiple security domains.

The CIPSO protocol will support a large number of security domains.  New
security domains will be registered with the Internet Assigned Numbers
Authority (IANA) and will be available with minimal difficulty to all
parties.

There is currently in progress another IP security option referred to as
IPSO (RFC 1108).  IPSO is designed to support the security labels used by
the U.S. Department of Defense.  CIPSO will be designed to provide labeling for
the commercial, U.S. civilian and non-U.S. communities.

The Trusted Systems Interoperability Group (TSIG) has developed a document
which defines a structure for the proposed CIPSO option.  The Working Group
will use this document as a foundation for developing an IETF CIPSO
specification.



Goals and Milestones:

  Ongoing Review outstanding comments/issues from mailing list.
          Continue the process to advance the Draft Standard to a Standard.

     Done Review and approve the Charter for the IETF CIPSO Working Group.
          Review revised TSIG CIPSO Specification.

     Done Review outstanding comments/issues from mailing list. Continue work
          on specification and prepare it for submission as an Internet-Draft
          by the end of May.

   Jul 91 Review outstanding comments/issues from mailing list.
          The specification will be submitted to the IESG for consideration
          as a Proposed Standard.

   Mar 92 Submit specification to the IESG for consideration as a Draft
          Standard.  There must be at least two interoperable implementations
          by this time.

DECnet Phase IV MIB (decnetiv)

Charter

Chair(s):
     Jonathan Saperia  <[e-mail]>

Network Management Area Director(s)
     J.R. Davin  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Status: concluded

Description of Working Group:

The DECNet Phase IV MIB Working Group will define MIB elements in the
experimental portion of the MIB which correspond to standard DECNet
Phase IV objects.  The Group will also define the access mechanisms
for collecting the data and transforming it into the proper ASN.1
structures to be stored in the MIB.

In accomplishing our goals, several areas will be addressed.  These
include: Identification of the DECNet objects to place in the MIB,
identification of the tree stucture and corresponding Object ID's for
the MIB elements, Generation of the ASN.1 for these new elements,
development of a proxy for non-decnet based management platforms, and
a test implementation.


Goals and Milestones:

     Done Review and approve the Charter and description of the Working Group,
          making any necessary changes.  At that meeting, the scope of the work
          will be defined and individual working assignments will be made.

     Done Mailing list discussion of Charter and collection of concerns.

     Done Review first draft document, determine necessary revisions. Follow up
          discussion will occur on mailing list.  If possible, prototype
          implementation to begin after revisions have been made.

     Done Make document an Internet Draft.  Continue revisions based on
          comments received at meeting and over e-mail.  Begin `real'
          implementations.

     Done Review final draft and if OK, give to IESG for publication as RFC.

   Jul 91  Revise document based on implementations.  Ask IESG to make the
          revision a Draft Standard.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  RFC  Stat Published    Title
------- -- ---------- -----------------------------------------
RFC1289 PS   Dec 91     DECnet Phase IV MIB Extensions
Distributed File Systems (dfs)

Charter

Chair(s):
     Peter Honeyman  <[e-mail]>

Transport and Services Area Director(s)
     Dave Borman  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

Trans- and inter-continental distributed file systems are upon us.  The
consequences to the Internet of distributed file system protocol design and
implementation decisions are sufficiently dire that we need to investigate
whether the protocols being deployed are really suitable for use on the
Internet.  There's some evidence that the opposite is true, e.g., some
distributed file systems protocols don't checksum their data,
don't use reasonable MTUs, don't offer credible authentication or
authorization services, don't attempt to avoid congestion, etc.
Accordingly, a Working Group on DFS has been formed by the IETF. The
Working Group will attempt to define guidelines for ways that distributed file
systems should make use of the network, and to consider whether any
existing distributed file systems are appropriate candidates for
Internet standardization.  The Working Group will also take a look at the
various file system protocols to see whether they make data more vulnerable.
This is a problem that is especially severe for Internet users, and a
place where the IETF may wish to exert some influence, both on vendor
offerings and user expectations.


Goals and Milestones:

   May 90 Generate an RFC with guidelines that define appropriate behavior of
          distributed file systems in an internet environment.

Dynamic Host Configuration (dhc)

Charter

Chair(s):
     Ralph Droms  <[e-mail]>

Internet Area Director(s)
     Philip Almquist  <[e-mail]>
     Stev Knowles  <[e-mail]>
     Dave Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           sol.bucknell.edu:~/dhcwg

Description of Working Group:

The purpose of this Working Group is the investigation of network
configuration and reconfiguration management.  We will determine those
configuration functions that can be automated, such as Internet
address assignment, gateway discovery and resource location, and those
which cannot be automated (i.e., those that must be managed by network
administrators).

Goals and Milestones:

          Write a bootp extensions document.

     Done We will identify (in the spirit of the Gateway Requirements and Host
          Requirements RFCs) the information required for hosts and gateways
          to: Exchange Internet packets with other hosts, Obtain packet routing
          information, Access the Domain Name System, and Access other local
          and remote services.

     Done We will summarize those mechanisms already in place for managing the
          information identified by Objective 1.

     Done We will suggest new mechanisms to manage the information identified
          by Objective 1.

     Done Having established what information and mechanisms are required for
          host operation, we will examine specific scenarios of dynamic host
          configuration and reconfiguration, and show how those scenarios can
          be resolved using existing or proposed management mechanisms.

Directory Information Services Infrastructure (disi)

Charter

Chair(s):
     Chris Weider  <[e-mail]>

User Services Area Director(s)
     Joyce Reynolds  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           pub/[e-mail]

Status: concluded

Description of Working Group:

The Directory Information Services (pilot) Infrastructure Working
Group is chartered to facilitate the deployment in the Internet of
Directory Services based on implementations of the X.500 standards.
It will facilitate this deployment by producing informational RFCs
intended to serve as a Directory Services ``Administrator's Guide''.
These RFCs will relate the current usage and scope of the X.500
standard and Directory Services in North America and the world, and
will contain information on the procurement, installation, and
operation of various implementations of the X.500 standard.  As the
various implementations of the X.500 standard work equally well over
TCP/IP and CLNP, the DISI Working Group shall not mandate specific
implementations or transport protocols.

The DISI Working Group is an offshoot of the OSI Directory Services
Group, and, accordingly, is a combined effort of the OSI Integration
Area and User Services Area of the IETF.  The current OSIDS Working
Group was chartered to smooth out technical differences in information
storage schema and difficulties in the interoperability and coherence
of various X.500 implementations.  The DISI Group is concerned solely
with expanding the Directory Services infrastructure. As DISI will be
providing infrastructure with an eye towards truly operational status,
DISI will need to form liaisons with COSINE, Paradise, and perhaps the
RARE WG3.

As a final document, the DISI Working Group shall write a Charter for
a new working group concerned with user services, integration,
maintenance, and operations of Directory Services, the Internet
Directory User Services Group.


Goals and Milestones:

     Done Submit an Internet-Draft on `Catalog of available X.500
          Implementations'

     Done Submit to the IESG the `Catalog of available X.500 Implementations'
          as an informational document.

     Done Submit an Internet-Draft on `Executive Introduction to X.500'

     Done Submit to the IESG the `Executive Introduction to X.500' as an
          informational document.

     Done Submit an Internet-Draft on `A Technical Overview of Directory
          ervices and X.500'.

     Done Submit to the IESG the `Technical Overview of Directory Services and
          X.500' as an informational document.

     Done First IETF Meeting: review and approve the Charter making any changes
          necessary. Examine needs and resources for the documentation to be
          produced, using as a first draft a document produced by Chris Weider,
          Merit, which will be brought to the IETF.  Assign writing
          assignments. Further work will be done electronically.

     Done Submit as an Internet-Draft the `Advanced Usages' paper.

   Jul 92 Submit as an Internet-Draft the `How to get registered' paper.

   Nov 92 Submit to the IESG the `How to get registered' paper as an
          informational document.

   Nov 92 Submit to the IESG the `Advanced Usages' paper as an informational
          document.

   Nov 92 Submit as an Internet-Draft the `Pilot Projects Catalog' paper.

   Nov 92 Submit as an Internet-Draft the `Where do I belong in the  Directory'
          paper.

   Mar 93 Submit to the IESG the `Pilot Projects Catalog' as an informational
          document.

   Mar 93 Submit to the IESG the `Where do I belong in the Directory' paper as
          an informational document.

   Mar 93 Submit as an Internet-Draft the `Guide to setting up a DSA'.

   Jul 93 Submit to the IESG the `Guide to setting up a DSA' as an
          informational document.


Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Oct 92 New     <draft-ietf-disi-x500-survey-00.txt>
                A Survey of Advanced Usages of X.500

RFC's:

  RFC  Stat Published    Title
------- -- ---------- -----------------------------------------
RFC1292      Jan 92     A Catalog of Available X.500 Implementations

RFC1308      Mar 92     Executive Introduction to Directory Services Using the
                        X.500 Protocol

RFC1309      Mar 92     Technical Overview of Directory Services Using the
                        X.500 Protocol
Domain Name System (dns)

Charter

Chair(s):
     Rob Austein  <[e-mail]>

Transport and Services Area Director(s)
     Dave Borman  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           nicfs.nic.ddn.mil:~/namedroppers/*.Z

Description of Working Group:

The DNS Working Group is concerned with the design, operation, and
evolution of the Domain Name System within the Internet.  As the Internet
continues to grow, we expect to serve as a focal point for work on scaling
problems within the current framework, work on protocol evolution as new
mechanisms become necessary, and documentation of current practice for DNS
implementors and administrators.  We are also responsible for oversight of
DNS activities by other groups within the IETF to the extent that we
review the impact such work will have on the DNS and make recomendations
to the working groups and IESG as necessary.  Since some of these are
ongoing tasks, we do not expect the working group to disband anytime soon.

Several issues are of particular concern at this time:

Scaling.  The DNS is the victim of its own success.  The global DNS
namespace has grown to the point where administering the top levels of
the tree is nearly as much work as the old NIC host table used to be.
We need to work on ways to distribute the load.  Some of the solutions
are likely to be technical, some political or economic; we still treat
the top-level DNS service the way we did when DARPA was footing the
bill, and the funding for that service is in the process of going away.

Security.  The DNS is a zero-security system; it is not even as
strong as the IP layer above which it operates.  As a result,
accidental spoofing (cache pollution) is an all-too-frequent occurance.
We need to make the DNS more robust against accidental corruption, and
must provide at least an optional authentication mechanism for that
portion of the community that wants one.  At the same time, we must not
cripple the existing system by drasticly increasing its bandwidth
consumption or by mandating use of cryptographic techniques that would
preclude worldwide distribution of DNS software.  The global DNS
database is exactly that, an existing world-wide database representing
hosts on six continents and (at least) forty-five countries.  A
solution that does not take this into account is not acceptable.

Management.  We have a draft document describing MIB extensions to
manage the DNS.  We also need to specify a standard way to dynamically
create and destroy DNS records; SNMP may be an appropriate tool for
this task, but we haven't yet specified enough of the details to know
for certain.  We need to examine the impact that a dynamic update
mechanism will have on the DNS, with particular attention to security
and scaling issues.

IPv7/Routing.  As the fur starts flying in the battle between the IPv7
proponants and the new-routing-architecture proponants, we expect that
groups on both sides will need some amount of support from the DNS.
Such support is likely to be minimal and straightforward, but these
proposals are likely to need "rush service" for whatever support they
require.  So the working group needs to monitor these activities, stay
involved, and generally do what it can to make sure that DNS support is
not a bottleneck.

We also need to examine the impact that any proposed IPv7 system would
have on the DNS, since the DNS database and protocols have special
provision for IP addresses.



Goals and Milestones:

          Post an Internet Draft of an operations guide for DNS Software.

          Post as an Internet Draft an implementation catalog for DNS software.

          Post an Internet Draft a description of the Responsible Person
          Record.

          Post an Internet draft specifying the addition of network naming
          capability to the DNS.

          Submit the DNS operators guide to the IESG for review as an
          Informational document.

          Submit the DNS implementation catalogue to the IESG for review as an
          Informational document.

          Submit to the IESG the document for load balancing in the DNS as an
          Informational document.

          Submit the responsible person record to the IESG for consideration as
          a proposed standard.

  Ongoing Monitor and offer technical support to the various groups working on
          the next version of IP.

          Post an Internet Draft of the "Big Zone" policy recommendations for
          root and first-level zone adminstraton.

          Submit the "Big Zone" policy document to the IESG for consideraton as
          a policy statement.

          Submit the specification for network naming to the IESG for
          consideration as a proposed standard.

     Done Post the DNS MIB as an Internet Draft.

   Feb 93 Submit the DNS MIB to the IESG for consideration as a Proposed
          Standard.

   Mar 93 Post an Internet Draft specifying the dynamic resource record
          creation and deletion.

   Mar 93 Submit to the IESG the incremental zone transfer mechanism as a
          Proposed Standard.

   Mar 93 List and prioritize the WG's goals, and pick a subset that is
          appropriate to pursue at the present time.

   Jun 93 Post an Internet Draft for adding load balancing capability to the
          DNS.

   Nov 93 Submit the proposal for dynamic resource record creation/deletion to
          the IESG for consideration as a Proposed Standard.

Ethernet MIB (ethermib)

Charter

Chair(s):
     Frank Kastenholz  <[e-mail]>

Network Management Area Director(s)
     J.R. Davin  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           not available

Status: concluded

Description of Working Group:

This Working Group is charged with resolving the outstanding
conformance issues with the Ethernet MIB in preparation for
its elevation from Proposed to Draft Standard status.
Specifically, this Working Group shall:

(1)  Develop a document explaining the rationale for assigning
     MANDATORY status to MIB variables which are optional in
     the relevant IEEE 802.3 specification (the technical
     basis for the Internet Ethernet MIB). This shall not be a
     standards-track document.

(2)  Develop an implementation report on the Ethernet MIB.
     This report shall cover MIB variables which are
     implemented in both Ethernet interface chips, and in
     software (i.e., drivers), and discuss the issues
     pertaining to both.  This report shall also summarize
     field experience with the MIB variables, especially
     concentrating on those variables which are in dispute.
     This document shall not be a standards-track document.
     While the Ethernet MIB is progressing through the
     standardization process, this document shall be
     periodically updated to reflect the latest implementation
     and operational experience.

(3)  Work to reconcile the differences regarding MANDATORY and
     OPTIONAL MIB variables with the IEEE 802.3 Management
     Specification.

(4)  Extend explicit invitations to the members, reviewers,
     and participants of the IEEE 802.3 committee to
     participate in the Working Group's efforts. This will
     ensure that as much Ethernet and IEEE 802.3 expertise
     as possible is available.

(5)  Maintain a liaison with the IEEE 802.3 committee. All
     documents produced by the Working Group will be forwarded
     to the IEEE 802.3 committee for their consideration as
     contributions to their efforts.

(6)  Modify the ``grouping'' of variables in the MIB, in the
     light of the implementation and operational experience
     gained, in order to effect the desired conformance
     groupings.

This Working Group is chartered to make only changes to the
MIB that fall into the following categories:

(1)  Division of variables into MIB groups.  This may
     necessitate adding or deleting groups and conceptual
     tables and moving variables among said groups and
     conceptual tables.  Doing so may require the addition or
     deletion of variables necessary to support the conceptual
     tables (e.g., the ...Table, ...Entry, and ...Index types of
     variables).  These changes may be necessary to align
     the MIB with the work of other standards bodies, the
     needs of implementors, and the needs of network managers
     in the Internet.

(2)  Changing the conformance requirements of the MIB groups
     in order to align the MIB with the work of other
     standards bodies, the needs of implementors, and the
     needs of network managers in the Internet.

(3)  Deleting variables from the MIB on the basis of
     implementation and operational experience showing that
     the variables are either unimplementable or have little
     practical operational value.

The Working Group is explicitly barred from making changes to
the definition or syntax of objects nor may the Working Group
add objects to the MIB except as may be required by Point 1
above.

Goals and Milestones:

     Done Draft Variable Status Rationale document.

     Done Develop Implementation Report.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  RFC  Stat Published    Title
------- -- ---------- -----------------------------------------
RFC1369      Oct 92     Implementation Notes and Experience for The Internet
                        Ethernet MIB

RFC1398 DS   Feb 93     Definitions of Managed Objects for the Ethernet-like
                        Interface Types
IP over FDDI (fddi)

Charter

Chair(s):
     Dave Katz  <[e-mail]>

Internet Area Director(s)
     Philip Almquist  <[e-mail]>
     Stev Knowles  <[e-mail]>
     Dave Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Status: concluded

Description of Working Group:

The IP over FDDI Working Group is chartered to create Internet
Standards for the use of the Internet Protocol and related protocols
on the Fiber Distributed Data Interface (FDDI) medium. This protocol
will provide support for the wide variety of FDDI configurations
(e.g., dual MAC stations) in such a way as to not constrain their
application, while maintaining the architectural philosophy of the
Internet protocol suite. The Group will maintain liaison with other
interested parties (e.g., ANSI ASC X3T9.5) to ensure technical
alignment with other standards.  This Group is specifically not
chartered to provide solutions to mixed media bridging problems.


Goals and Milestones:

     Done Write a document specifying the use of IP on a single MAC FDDI
          station.

   Aug 90 Write a document specifying the use of IP on dual MAC FDDI stations.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  RFC  Stat Published    Title
------- -- ---------- -----------------------------------------
RFC1188 DS   Oct 90     A Proposed Standard for the Transmission of IP
                        Datagrams over FDDI Networks

RFC1390  S   Jan 93     Transmission of IP and ARP over FDDI Networks
FDDI MIB (fddimib)

Charter

Chair(s):
     Jeffrey Case  <[e-mail]>

Network Management Area Director(s)
     J.R. Davin  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The FDDI MIB Working Group is chartered to define a MIB for FDDI
devices that is consistent with relevant FDDI specifications produced
by ANSI.  All definitions produced by this Working Group will be
consistent with the SNMP network management framework and other
internet-standard MIBs for SNMP.

Goals and Milestones:

     Done ``Final'' initial draft of required get/set variables.

     Done Initial implementations of required get/set variables.

     Done Revised ``final'' draft of required get/set variables.

     Done Adoption of draft of required get/set variables.

   Mar 92 Submit the FDDI MIB to the IESG for consideration as a Proposed or
          Draft Standard depending on the magnitude of changes to RFC 1285.

     Done Hold a meeting at the November IETF Plenary.

   Dec 92 Post an Internet-Draft aligned with current the current ANSI document
          factoring in implementation experience with RFC 1285.

Host Resources MIB (hostmib)

Charter

Chair(s):
     Steven Waldbusser  <[e-mail]>

Network Management Area Director(s)
     J.R. Davin  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The Host Resources MIB Working Group is chartered to produce exactly
one document that defines SNMP MIB objects that instrument
characteristics common to all internet hosts. The goal of this work is
to address the urgent operational need in the internet community for
management of host systems. Owing to this urgency, the Working Group
will focus exclusively on the alignment of existing MIB technology in
order to achieve common solutions in a timely manner.

For purposes of this effort, the term ``internet host'' is construed to
mean any computer that communicates with other similar computers
attached to the internet and that is directly used by one or more human
beings. Although the work of the Group does not necessarily apply to
devices whose primary function is communications services (e.g.,
terminal servers, routers, bridges, monitoring equipment), such
relevance is not explicitly precluded.  The single MIB produced shall
instrument attributes common to all internet hosts including, for
example, both personal computers and systems that run variants of
Unix.

The methodology of this Working Group is to focus entirely on the
alignment of existing, enterprise-specific MIBs for SNMP that are
relevant to its task. The Group will work towards its goal by
distillation and generalization of these existing MIBs into a single,
common MIB definition.

Owing to the urgent operational need for managing host systems, this
effort will not be comprehensive in scope. Rather, the MIB produced by
this Group will be confined to critical information about hardware and
software configuration, processor and memory use, and data storage
capacities, backup, and use.

Owing to the lack of a well-understood and accepted architecture, the
Working Group will not address in any way, mechanisms that could be used
to monitor or control the use of licensed software products.

All definitions produced by the Group will be consistent with the SNMP
network management framework and all other internet-standard MIBs for
SNMP.  Wherever possible, the definitions produced will make use of or
align with relevant work in progress with chartered working groups of
the IETF. Also, wherever possible, the Working Group will take into
consideration pre-existing, stable work produced by other, accredited
standards bodies.

Goals and Milestones:

     Done First Working Group meeting.  Discuss the initial proposed document.

     Done Post an Internet-Draft describing the Host Resources MIB.

     Done Hold an interim meeting to discuss the current document.

     Done Meet at the IETF plenary to identify changes necessary for Working
          Group closure.

   Dec 92 Submit the Host Resources MIB to the IESG as a Proposed Standard.

IEEE 802.3 Hub MIB (hubmib)

Charter

Chair(s):
     Keith McCloghrie  <[e-mail]>
     Donna McMaster  <[e-mail]>

Network Management Area Director(s)
     J.R. Davin  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           sweetwater.synoptics.com"~/pub/hubmib

Description of Working Group:

This Working Group will produce a document describing MIB objects for
use in managing Ethernet-like hubs.  A hub is defined as a multiport
repeater that conforms to Section 9, ``Repeater Unit for 10 Mb/s
Baseband Networks'' in the IEEE 802.3/ISO 8802-3 CSMA/CD standard (2nd
edition, Sept. 1990).  These Hub MIB objects may be used to manage
non-standard repeater-like devices, but defining objects to describe
vendor-specific properties of non-standard repeater-like devices are
outside the scope of this Working Group.  The MIB object definitions
produced will be for use by SNMP and will be consistent with other SNMP
objects, conventions, and definitions.

In order to minimize the instrumentation burden on managed agents, the
MIB definitions produced by the Working Group will, wherever feasible,
be semantically consistent with the managed objects defined in the IEEE
draft standard P802.3K, ``Layer Management for Hub Devices.''  The
Working Group will base its work on the draft that is the output of the
July 1991 IEEE 802 plenary meeting.  The Working Group will take
special cognizance of Appendix B of that specification that sketches a
possible realization of the relevant managed objects in the SNMP
idiom.

Consistent with the IETF policy regarding the treatment of MIB
definitions produced by other standards bodies, the Working Group may
choose to consider only a subset of those objects in the IEEE
specification and is under no obligation to consider (even for
``Optional'' status) all objects defined in the IEEE specification.
Moreover, when justified by special operational needs of the community,
the Working Group may choose to define additional MIB objects that are
not present in the IEEE specification.

Although the definitions produced by the Working Group should be
architecturally consistent with MIB-II and related MIBs wherever
possible, the Charter of the Working Group does not extend to
perturbing the conceptual models implicit in MIB-II or related MIBs in
order to accommodate 802.3 Hubs.  In particular, to the extent that the
notion of a ``port'' in an 802.3 Hub is not consistent with the notion
of a network ``interface'' as articulated in MIB-II, it shall be
modelled independently by objects defined in the Working Group.

Because the structure of 802.3 Hub implementations varies widely, the
Working Group shall take special care that its definitions reflect a
generic and consistent architectural model of Hub management rather
than the structure of particular Hub implementations.

The IEEE Hub Management draft allows an implementor to separate the ports in a hub into groups, if desired (i.e., a vendor might choose to represent field-replaceable unites as groups of ports so that the port numbering would match a modular hardware implementation.)  Because the Working Group Charter
does not extend to consideration of fault-tolerant, highly-available systems
in general, its treatment of these groups of ports in an 802.3 Hub (if any)
shall be specific to Hub management and without impact upon other portions of
the MIB.

The Working Group is further chartered at its discretion to define an
SNMP MIB for management of IEEE 802.3 Medium Access Units (MAUs).  An
802.3 Medium Attachment Unit (MAU) attaches a repeater port or
Ethernet-like interface to the local network medium. The scope of this
work may include several types of MAU units: 10BASE5 (thick coax),
10BASE2 (thin coax), 10BASE-T (twisted pair), FOIRL and 10BASE-F (fiber
optic).  Managed objects defined as part of the MAU MIB task may, for
example, represent such information as MAU type, link status, and
jabbering indications.


Goals and Milestones:

     Done Distribute first draft of documents and discuss via E-mail.

     Done Working Group meeting as part of IETF to review documents.

     Done Distribute updated documents for more E-mail discussion.

     Done Review all documents at IETF meeting.  Hopefully recommend
          advancement with specified editing changes.

     Done Documents available with specified changes incorporated.

     Done Submit the Repeater MIB to the IESG for consideration as a Proposed
          Standard.

   Nov 92 Post the Media Access Unit MIB Definition as an Internet-Draft.

   Apr 93 Submit the Media Access Unit MIB to the IESG for consideration as a
          Proposed Standard.

Internet Anonymous FTP Archives (iafa)

Charter

Chair(s):
     Peter Deutsch  <[e-mail]>
     Alan Emtage  <[e-mail]>

User Services Area Director(s)
     Joyce Reynolds  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           archive.cc.mcgill.ca:~/pub/iafa-archive

Description of Working Group:

The Internet Anonymous FTP Archives Working Group is chartered to
define a set of recommended standard procedures for the access and
administration of anonymous ftp archive sites on the Internet.  Such a
set of procedures will provide a framework for:

(a) Allowing the inexperienced Internet user the ability to more
    easily navigate the hundreds of publically accessible archive sites.

(b) Allowing users and network-based tools to retrieve specific site
    information such as access policies, contact information, possible
    areas of information specialization, archived package descriptions, etc.,
    in a standardized manner.

Particular emphasis will be placed on the possible impact of these
procedures on the FTP site administrators.

Attention will be paid to the impact of newer archive indexing and
access tools on the operation of such archive sites. A set of
suggestions will be offered to allow archive site administrators to
better integrate their offerings with such tools as they are
developed.

The security of the anonymous FTP site configuration will also be
considered to be an integral part of this document. It is expected
that remote management of the archives will be adequately handled by
existing network management procedures.


Goals and Milestones:

     Done First IETF Meeting: review and approve the Charter making any changes
          deemed necessary. Examine the scope of the recommended procedures and
          impact on site administrators. Assign writing assignments for the
          first draft of the documents.

   Mar 92 Review first draft and determine necessary revisions. Follow up
          discussion will occur on mailing list.

   Jun 92 Make document an Internet-Draft. Continue revisions based on comments
          at IETF and on the mailing list.

   Nov 92 Fourth IETF meeting. Review final drafts and if OK, give to IESG for
          publication as an RFC.

TCP Client Identity Protocol (ident)

Charter

Chair(s):
     Mike St. Johns  <[e-mail]>

Security Area Director(s)
     Steve Crocker  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           cnri.reston.va.us:~/ietf.mailing.lists/ident/*

Description of Working Group:

The TCP Client Identity Protocol Working Group is chartered to define
a protocol for returning the identity of the user initiating a TCP
connection.  When a client on host A initiates a TCP connection to
host B, host B may query a server on host A to determine the identity
of the client on host A.  The primary purpose of this protocol is to
record the identity of requesters initiating a connection.

This work is a clarification and standardization of the Experimental
Protocol currently published as RFC 931.



Goals and Milestones:

     Done Review implementations, and resolve outstanding issues in preparation
          for Draft Standard.

     Done Post an Internet-Draft of the revised RFC 931 Identity Server
          Protocol.

     Done Submit the Identity Server Protocol to the IESG for consideration as
          a Proposed Standard.

Inter-Domain Multicast Routing (idmr)

Charter

Chair(s):
     Tony Ballardie  <[e-mail]>

Internet Area Director(s)
     Philip Almquist  <[e-mail]>
     Stev Knowles  <[e-mail]>
     Dave Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:
     To Subscribe:
     Archive:

Description of Working Group:

No description available

Goals and Milestones:

Inter-Domain Policy Routing (idpr)

Charter

Chair(s):
     Martha Steenstrup  <[e-mail]>

Routing Area Director(s)
     Bob Hinden  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The Inter Domain Policy Routing Working Group is chartered to
develop an architecture and set of protocols for policy routing
among large numbers of arbitrarily interconnected administrative
domains.

Goals and Milestones:

     Done Write an architecture document.

     Done Draft Protocol Specification of key elements of the protocol.

     Done Develop a prototype implementation of the protocols.

     Done Submit the IDPR Specification to the IESG as a Proposed Standard.

Integrated Directory Services (ids)

Charter

Chair(s):
     Chris Weider  <[e-mail]>
     Tim Howes  <[e-mail]>

User Services Area Director(s)
     Joyce Reynolds  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           merit.edu:~/pub/ids-archive

Description of Working Group:

The Integrated Directory Services Working Group (IDS) is chartered to
facilitate the integration and interoperability of current and future
directory services into a unified directory service. This work will
unite directory services based on a heterogeneous set of directory
services protocols (X.500, WHOIS++, etc.). In addition to specifying
technical requirements for the integration, the IDS Group will also
contribute to the administrative and maintenance issues of directory
service offerings by publishing guidelines on directory data integrity,
maintenance, security, and privacy and legal issues for users and
administrators of directories.

IDS will also assume responsibility for the completion of the
outstanding Directory Information Services Infrastructure (DISI)
Internet-Drafts, which are all specific to the X.500 protocol, and for
the maintenance of FYI 11, ``A catalog of available X.500
implementations''.

IDS will need to liase with the groups working on development and
deployment of the various directory service protocols.

The IDS Working Group is a combined effort of the Applications Area and
the User Services Area of the IETF.

Goals and Milestones:

  Ongoing Track emerging directory service protocols to specify standards for
          interoperation with existing protocols.

  Ongoing Liase with groups working on deployment and development of directory
          services to locate and fix interoperability problems.

  Ongoing Identify unfilled needs of directory service offerers,
          administrators, and users.

   Mar 93 Submit to the IESG the DISI ``Advanced Usages of X.500'' paper as an
          informational document.

   Mar 93 Submit to the IESG the DISI ``X.500 Pilot Project Catalog'' paper as
          an informational document.

   Mar 93 Submit to the IESG the 1993 revision of FYI 11, ``A catalog of
          available X.500 implementations'' as an informational document.

   Mar 93 Submit as an Internet-Draft a ``Specifications for interoperability
          between WHOIS++ and X.500''.

   Jul 93 Submit as an Internet-Draft a ``Guide to administering a directory
          service'', which covers data integrity, maintenance, privacy and
          legal issues, and security.

   Jul 93 Submit as an Internet-Draft a ``Catalog of available WHOIS++
          implementations''.

   Nov 93 Submit to the IESG the ``Specifications for interoperability between
          WHOIS++ and X.500'' as a standards document.

   Nov 93 Submit as an Internet-Draft a ``User's guide to directory services on
          the Internet''.

   Mar 94 Submit to the IESG the ``Guide to administering a directory service''
          as an informational document.

   Mar 94 Submit to the IESG the 1994 revision of FYI 11.

   Mar 94 Submit to the IESG the ``Catalog of available WHOIS++
          implementations'' as an informational document.

Integration of Internet Information Resources (iiir)

Charter

Chair(s):
     Chris Weider  <[e-mail]>

User Services Area Director(s)
     Joyce Reynolds  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           merit.edu:~/pub/iiir-archive

Description of Working Group:

The Integration of Internet Information Resources Working Group (IIIR)
is chartered to facilitate interoperability between Internet
Information Services, and to develop, specify, and align protocols
designed to integrate the plethora of Internet information services
(WAIS, ARCHIE, Prospero, etc.) into a single ``virtually unified
information service'' (VUIS). Such protocols would include (but are not
limited to) update protocols for distributed servers, a `query routing
protocol' to pass queries between existing services, protocols for
gateways between existing and future services, and standard exchange
formats (perhaps based on Z39.50) for cross-listing specific
information.

Also, where necessary, IIIR will create technical documentation for
protocols used for information services in the Internet.

Goals and Milestones:

  Ongoing Track emerging Internet information services in order to specify
          technical requirements for their integration into the VUIS.

  Ongoing Liaise with other groups working on deployment and integration of
          Internet information services: e.g., The Coalition for Networked
          Information, RARE Working Group 3, etc.

  Ongoing Create specifications for interoperability between Internet
          information systems.

   Mar 93  Post an Internet Draft on 'A vision of integrated information
          resources'.

   Mar 93 Post an Internet Draft on 'Taxonomy of Internet Information
          Services'.

   Jul 93 Submit final version of 'A vision of integrated information
          resources' to the IESG as an informational RFC.

   Jul 93 Submit final version of 'Taxonomy of Internet Information Services'
          to the IESG as an informational RFC.

   Nov 93 Post an Internet-Draft defining common exchange formats.

   Nov 93 Post an Internet Draft defining a Query Routing Protocol.

   Mar 94 Submit final version of common exchange format to the IESG as a
          Proposed Standard.

   Jul 94 Submit final version of Query Routing Protocol to the IESG as a
          Proposed Standard.

IP Address Encapsulation (ipae)

Charter

Chair(s):
     Dave Crocker  <[e-mail]>

Internet Area Director(s)
     Philip Almquist  <[e-mail]>
     Stev Knowles  <[e-mail]>
     Dave Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           parcftp.xerox.com:~/pub/ip-encaps/

Description of Working Group:

The IPAE Working Group seeks to develop a capability for extending IP to
support larger addresses while minimizing impact on the installed base of IP
users.  An enhancement to the current system is mandatory due to the
limitations of the current 32 bit IP addresses.  IPAE seeks to upgrade the
current system, rather than to replace the Internet Protocol.  The approach
taken will be to sandwhich a small addressing layer, above IP but below TCP
or UDP, with the new layer having its own IP Protocol-ID.  This special layer
will thereby encapsulate new, larger, globally-unique addresses for source
and destination, as well as any other fields of information that are
considered essential.

The specificaton effort will attend to issues of transition and coexistance,
among unmodified ``IP'' hosts and hosts which support ``IPAE'' hosts The
IPAE approach will develop a framework to organize the Internet into areas
called ``IP Addressing Commonwealths'' within which 32-bit IP addresses are
unique and are part of a larger, globally-unique Internet addressing scheme.
It is a goal of this effort to avoid requiring any router within a
Commonwealth to be modified, but any host wishing full Internet connectivity
will need to support IPAE eventually.  Further, any system wishing to support
full IPAE addresses will need to be modified, including network management
software.

Goals and Milestones:

     Done Review and approve the Charter at the first Working Group meeting.

     Done Post the initial IPAE specification as an Internet-Draft.

   Aug 92 Post the initial ``Addressing'' specification as an Internet-Draft.

   Sep 92 Post the ``Implementation and Transition'' specification as an
          Internet-Draft.

     Done Post the report to the IESG as an Internet-Draft.

     Done Present work of the IPAE Working Group to the IETF.

IP Authentication (ipauth)

Charter

Chair(s):
     Jeffrey Schiller  <[e-mail]>

Security Area Director(s)
     Steve Crocker  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Status: concluded

Description of Working Group:

To brainstorm issues related to providing for the security and
integrity of information on the Internet, with emphasis on those
protocols used to operate and control the network.  To propose open
standard solutions to problems in network authentication.

Goals and Milestones:

          RFC specifying an authentication format which supports multiple
          authentication systems.

          Document discussing the cost/benefit tradeoffs of various generic
          approaches to solving the authentication problem in the Internet
          context.

          Document to act as a protocol designers guide to authentication.

          RFC proposing A Key Distribution System (emphasis on ``A'' as opposed
          to ``THE''). MIT's Kerberos seems the most likely candidate here.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  None to date.
OSI IDRP for IP over IP (ipidrp)

Charter

Chair(s):
     Sue Hares  <[e-mail]>

Routing Area Director(s)
     Bob Hinden  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           merit.edu:~/pub/archive/idrp

Description of Working Group:

The IDRP for IP over IP Working Group is chartered to standardize and promote
the use of IDRP (ISO Inter-Domain Routing Protocol) as a scalable inter-
autonomous system routing protocol capable of supporting Policy Based Routing
for TCP/IP internets.  The objective is to take IDRP, as it is defined by ISO
standards, and to define backward compatible extensions and/or network
adaptation layers to enable this protocol to be used in the TCP/IP internets.
If any ISO standardization efforts overlap this area of work, it is intended
that the ISO work will supersede the standards proposed by this Group.

1) IDRP for IP over IP document (standards track)

   This document contains the appropriate adaptations of the IDRP protocol
   definition that enables it to be used as a protocol for exchange of
   ``inter-autonomous system information'' among routers to support
   forwarding of IP packets across multiple autonomous systems.

2) IDRP MIB document (standards track)

   This document contains the MIB Definitions for IDRP.  These MIB
   Definitions are done in two parts; IDRP General MIB, and IDRP for  IP
   MIB. An appendix is planned; IDRP For IP GDMO

3) IDRP - OSPF Interactions (standards track)

   This document will specify the interactions between IDRP and OSPF.
   This document will be based on a combination of BGP-OSPF interactions
   document and IDRP - ISIS interaction document.

4) IDRP for IP Usage document (standards track)

   Most of the IDRP for IP Usage will reference the CIDR  (Supernetting
   document) Internet Draft.  Any additional terms or protocol definitions
   needed for IDRP for IP will also be specified here.

Goals and Milestones:

     Done IDRP for IP submitted for Internet-Draft.

   Jun 92 IDRP MIB document submitted for Internet-Draft.

   Jun 92 IDRP - OSPF Interactions document submitted for Internet-Draft.

   Jun 92 IDRP Usage document submitted for Internet-Draft.

   Nov 92 IDRP for IP submitted to the IESG for Proposed Standard.

   Nov 92 IDRP Usage document submitted to the IESG for Proposed Standard.

   Nov 92 IDPR MIB Submitted to the IESG for Proposed Standard.

   Nov 92 IDRP - OSPF Interactions document submitted to the IESG for Proposed
          Standard.

IP OSI Mutual Encapsulation (ipiso)

Charter

Chair(s):
        <[e-mail]>

Internet Area Director(s)
     Philip Almquist  <[e-mail]>
     Stev Knowles  <[e-mail]>
     Dave Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:
     To Subscribe:
     Archive:

Status: proposed

Description of Working Group:

No description available

Goals and Milestones:


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  None to date.
IP over Large Public Data Networks (iplpdn)

Charter

Chair(s):
     George Clapp  <[e-mail]>

Internet Area Director(s)
     Philip Almquist  <[e-mail]>
     Stev Knowles  <[e-mail]>
     Dave Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           cnri.reston.va.us:~/ietf.mail.archives/iplpdn/*

Description of Working Group:

The IP over Large Public Data Networks Working Group will
specify the operation of the TCP/IP protocol suite over Public Data
Networks (PDNs) such as SMDS, ISDN, X.25 PDNs, and Frame Relay.  The
Working Group will develop and define algorithms for the resolution of
IP addresses and for the routing of IP datagrams over large,
potentially global, public data networks.

The IP over SMDS Working Group has defined the operation of the
Internet protocols when SMDS is used to support relatively small
virtual private networks, or Logical IP Subnets (LISs).  Issues
arising from public and global connectivity were delegated to the
IPLPDN Working Group.

The IPLPDN Working Group will also continue the work of the Private Data Network
Routing Working Group (PDNROUT) on X.25 PDNs.  This work will be
extended to include call management and the use of the ISDN B channels
for the transport of IP datagrams.

Address resolution and routing over Frame Relay will also be
discussed.


Goals and Milestones:

          Address resolution of Internet addresses to SMDS E.164
          addresses, to ISDN E.164 addresses, to X.121 addresses,
          and to Frame Relay Data Link Connection Identifiers (DLCIs).
          The algorithm(s) may be defined in either a single or in multiple
          documents.

          Routing of IP datagrams across very large internets implemented
          SMDS and on other PDNs.

          Management of ISDN and of X.25 connections and the use
          of the ISDN B and D channels.

     Done Establish priorities and dates of completion for documents.

Internet Protocol Security Protocol (ipsec)

Charter

Chair(s):
     Al Hoover  <[e-mail]>
     Paul Lambert  <[e-mail]>

Security Area Director(s)
     Steve Crocker  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp.ans.net:~/pub/archive/ipsec

Description of Working Group:

Rapid advances in communication technology have accentuated the need
for security in the Internet.  The IP Security Protocol Working Group
(IPSEC) will develop mechanisms to protect client protocols of IP.
A security protocol in the network layer will be developed to provide
cryptographic security services that will flexibly support combinations
of authentication, integrity, access control, and confidentiality.  The
protocol formats for the IP Security Protocol (IPSP) will be independent of
the cryptographic algorithm.  The preliminary goals will specifically
pursue host-to-host security followed by subnet-to-subnet and host-to-
subnet topologies.

Protocol and cryptographic techniques will also be developed to support
the key management requirements of the network layer security.  The key
management will be specified as an application layer protocol that is
independent of the lower layer security protocol.  The protocol will
initially support public key based techniques.  Flexibility in the
protocol will allow eventual support of Key Distribution Center (KDC -
such as Kerberos) and manual distribution approaches.

Goals and Milestones:

   Mar 93 Post as an Internet-Draft the IP Security Protocol.

   Jul 93 Post as an Interenet-Draft the specification for Internet Key
          Management.

   Nov 93 Report on Pilot Implementation of the IP Security Protocol. Update
          Protocol as needed.

   Mar 94 Report on Pilot implementation of the Internet Key Management
          Protocol. Update Internet-Draft as needed.

   Jul 94 Submit the IP Security Protocol to the IESG for consideration as a
          Proposed Standard.

   Jul 94 Submit the Key Management Protocol to the IESG for consideration as a
          Proposed Standard.

ISIS for IP Internets (isis)

Charter

Chair(s):
     Ross Callon  <[e-mail]>

Routing Area Director(s)
     Bob Hinden  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The IETF ISIS Working Group will develop additions to the existing
OSI IS-IS Routing Protocol to support IP environments and dual (OSI
and IP) environments.

Goals and Milestones:

     Done Liaison with the IS-IS editor for OSI in case any minor changes to
          IS-IS are necessary.

     Done Develop an extension to the OSI IS-IS protocols which will allow use
          of IS-IS to support IP environments, and which will allow use of
          IS-IS as a single routing protocol to support both IP and OSI in dual
          environments.

     Done Post a revision of the IS-IS as an Internet-Draft.

   Mar 93 Submit the revised IS-IS to the IESG as a Draft Standard.

   Mar 93 Submit the IS-IS MIB to the IESG as a Proposed Standard.

Internet School Networking (isn)

Charter

Chair(s):
     John Clement  <[e-mail]>
     Arthur St. George  <[e-mail]>
     Connie Stout  <[e-mail]>

User Services Area Director(s)
     Joyce Reynolds  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail] body: sub isn-wg <name>
     Archive:

Description of Working Group:

The Internet School Networking Working Group is chartered to
facilitate the connection of the United States' K-12
(Kindergarten-12th Grade) schools, public and private, to the
Internet, and school networking in general.

It is critically important that national networking for K-12 education
proceed along established lines of protocol, using existing network
structures.  The Working Group's first priority will be to establish
guidelines for specialized user interfaces.  K-12 networking will also
require other support services, such as directories, online and
hotline help, specialized training programs and collaborative projects
with instructional and curriculum groups, disciplinary groups and
postsecondary institutions.

While the initial focus is school networking in the U.S., the Working
Group will coordinate its efforts with similar activities in other
countries and regions of the world.


Goals and Milestones:

     Done Meet for the first time at IETF and establish approval of Charter.
          Examine the status of projects in process when Working Group was
          created. Begin work on list of deliverables.

   Jan 92 Release X.500 ``K-12 People Directory'' version in collaboration with
          Merit.  Develop plans and milestones for K-12 Resources Directory.

   Mar 92 First draft of information packet document for computing directors to
          assist them in connecting K-12 schools.  First draft of user
          interface guideline statement.

   May 92 Release X.500 K-12 Resource Directory version in collaboration with
          Merit.  Present final draft guideline statement.

Internet User Population (iup)

Charter

Chair(s):
     Craig Partridge  <[e-mail]>

User Services Area Director(s)
     Joyce Reynolds  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Status: concluded

Description of Working Group:

To devise and carry out an experiment to estimate the size of the
Internet user population.

Goals and Milestones:

     Done Prepare an article for publication in a networking magazine.

     Done Write a description of the experimental procedure.

     Done Write an RFC that gives the results of the experiment.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  None to date.
LAN Manager (lanman)

Charter

Chair(s):
     David Perkins  <[e-mail]>

Network Management Area Director(s)
     J.R. Davin  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Status: concluded

Description of Working Group:

This working group is chartered to define and maintain the MIB and
relevant related mechanisms needed to allow management of workgroup
PCs and servers that are using the Microsoft Lan Manager protocols.
These protocols provide file and print service and mechanisms for
development of application server-client systems such as ones for mail
or SQL database.




Goals and Milestones:

          Define an upwards compatible MIB for LAN Manager version 2.x.

          Work to influence Microsoft, the developer of LAN Manager, to
          add/change APIs so that MIB developed can be consistant in style
          and information content with MIBs developed by other MIB Working
          Groups.




Internet-Drafts:

  No Current Internet drafts.

RFC's:

  None to date.

Automated Internet Mailing List Services (list)

Charter

Chair(s):
     David Lippke  <[e-mail]>

Applications Area Director(s)
     Russ Hobby  <[e-mail]>
     Erik Huizer  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           pub/[e-mail]

Status: concluded

Description of Working Group:

This Working Group will concern itself with ``list servers'', i.e.,
advanced mail exploders/reflectors which provide services such as
automated subscription, archive maintenance, and coordination with
similar systems on the network.

The Group will initially focus its activities towards establishing a
baseline user interface.  Although most current systems support a
command set patterned after Eric Thomas' BITNET LISTSERV, there is
wide variance in the options supported and in the general patterns of
interaction.  This results in a great deal of user confusion.  The
Working Group's interface definition will address this by establishing
a set of commands, options, interactions, and procedures which will
(hopefully) be supported by all list servers as a subset of their full
repertoire.

As a part of the user interface work, the Group will also define an
authentication service for users' list server transactions.  Toward
this end, and to address the privacy issue, the Group will consult
with the Security Area Advisory Group (SAAG).

The second phase of the Group's work will be to provide for the
interconnection and coordination of list servers.  Experience with the
BITNET LISTSERV has shown that it is important for users be able to
view the collection of list servers on the network as an integrated
whole.  Ideally, users should only have to deal with their local
mailing list service---which knows where all public lists are, what
they are, and is able to act on the user's behalf with respect to
them.  Interconnecting list servers allows this ``integrated user view''
to be created and also lets issues such as traffic minimization,
timely distribution, and load sharing to be more easily addressed.
Consequently, the Working Group will define the conceptual models,
communication methods, and extensions to prior work which are
necessary to bring this interconnection and coordination about.

It is anticipated that further work on issues of authentication and
privacy will continue in parallel with the ``integration'' effort ---
perhaps manifesting itself as a separate RFC which extends the user
interface definition produced during the first phase.


Goals and Milestones:

          Submit interconnection/coordination definition document to the IESG
          for publication as a Proposed Standard.

     Done Review the Group's Charter and begin work on the user interface
          definition.

   Nov 91 Resolve outstanding issues with the user interface definition and
          prepare document for IESG submission.  Begin work to address the
          interconnection/coordination issue.

   Jan 92 Submit user interface definition document to IESG as a Proposed
          Standard.

   Mar 92 Focus the interconnection/coordination work.  Finalize and document
          settled issues.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  None to date.
MIME-MHS Interworking (mimemhs)

Charter

Chair(s):
     Steve Thompson  <[e-mail]>

Applications Area Director(s)
     Russ Hobby  <[e-mail]>
     Erik Huizer  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

MIME, (Multipurpose Internet Mail Extensions) is currently a Proposed Standard. MIME redefines the format of message bodies to allow multi-part textual
and non-textual message bodies to be represented and exchanged without
loss of information.  With the introduction of MIME as a Proposed
Standard it is now possible to define mappings between RFC-822
content-types and X.400 body parts.  The MIME-MHS Interworking Working Group is
chartered to develop these mappings, providing an emphasis on both
interworking between Internet and MHS mail environments and also on
tunneling through these environments. These mappings will be made in
the context of an RFC-1148bis environment.

Goals and Milestones:

     Done Post an Internet-Draft describing MIME-MHS Interworking.

     Done Post an Internet-Draft describing the ``core'' set of Registered
          conversions for bodyparts.

   Jul 92 Submit a completed document to the IESG describing MIME-MHS
          Interworking as a Proposed Standard.

   Jul 92 Submit the ``core'' bodyparts document to the IESG as a Proposed
          Standard.

Multi-Media Bridging (mmb)

Charter

Chair(s):
     Jeffrey Fitzgerald  <[e-mail]>

Internet Area Director(s)
     Philip Almquist  <[e-mail]>
     Stev Knowles  <[e-mail]>
     Dave Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Status: concluded

Description of Working Group:


  The Multi-Media Bridge Working Group has the task of addressing
  the function of multi-media bridges within TCP/IP networks.  This
  is viewed as necessary at this time because of the proliferation
  of these devices.

  The first goal of the Group is to document the multi-media bridge
  technology and point out the issues raised by having these devices
  in a TCP/IP internet.  If there are problems which can be addressed
  the Group will work towards resolving them and documenting the
  solutions.



Goals and Milestones:

     Done Finalize Charter of Group.

   Aug 91 Document mulit-media bridging technology and its affect on TCP/IP
          Internets.

   Aug 91 Document issues to be addressed by Working Group.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  None to date.
IP Routing for Wireless/Mobile Hosts (mobileip)

Charter

Chair(s):
     Steve Deering  <[e-mail]>

Routing Area Director(s)
     Bob Hinden  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           parcftp.xerox.com:~/pub/mobile-ip/mail-archive

Description of Working Group:

The Mobile IP Working Group is chartered to develop or adopt
architectures and protocols to support mobility within the Internet.
In the near-term, protocols for supporting transparent host ``roaming''
among different subnetworks and different media (e.g., LANs, dial-up
links, and wireless communication channels) shall be developed and
entered into the Internet Standards track.  The work is expected to
consist mainly of new and/or revised protocols at the (inter) network
layer, but may also include proposed modifications to higher-layer
protocols (e.g., transport or directory).  However, it shall be a
requirement that the proposed solutions allow mobile hosts to
interoperate with existing Internet systems.

Longer term, the Group may address, to the extent not covered by the
mobile host solutions, other types of internet mobility, such as
mobile subnets (e.g., a local network within a vehicle), or mobile
clusters of subnets (e.g., a collection of hosts, routers, and subnets
within a large vehicle, like a ship or spacecraft, or a collection of
wireless, mobile routers that provide a dynamically changing internet
topology).

Goals and Milestones:

     Done Review and approve the Charter, making any changes deemed necessary.

   Nov 92 Post an Internet-Draft documenting the Mobile Hosts protocol.

   Mar 93 Review the Charter of the Mobile IP Working Group for additional work
          required to facilitate non-host mobility.

   Mar 93 Submit the Mobile Host Protocol to the IESG as a Proposed Standard.

Multicast Extensions to OSPF (mospf)

Charter

Chair(s):
     Steve Deering  <[e-mail]>

Routing Area Director(s)
     Bob Hinden  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

This Working Group will extend the OSPF routing protocol so that it
will be able to efficiently route IP multicast packets.  This will
produce a new (multicast) version of the OSPF protocol, which will be
as compatible as possible with the present version (packet formats and
most of the algorithms will hopefully remain unaltered).

Goals and Milestones:

     Done Become familiar with the IGMP protocol as documented in RFC 1112.
          Survey existing work on multicast routing, in particular, Steve
          Deering's paper ``Multicast Routing in Internetworks and Extended
          LANs''. Identify areas where OSPF must be extended to support
          multicast  routing.  Identify possible points of contention.

     Done Review outline of proposed changes to OSPF.  Identify any unresolved
          issues and, if possible, resolve them.

     Done We should have a draft specification.  Discuss the specification and
          make any necessary changes.  Discuss implementation methods, using as
          an example, the existing BSD OSPF code, written by Rob Coltun of the
          University of Maryland.

     Done Report on implementations of the new multicast OSPF.  Fix any
          problems in the specification that were found by the implementations.

   Feb 92 Submit the MOSPF Specification to the IESG as a Proposed Standard.

SNMP over a Multi-protocol Internet (mpsnmp)

Charter

Chair(s):
     Theodore Brunner  <[e-mail]>

Internet Area Director(s)
     Philip Almquist  <[e-mail]>
     Stev Knowles  <[e-mail]>
     Dave Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           thumper.bellcore.com:~/pub/snmp-foo/archive

Description of Working Group:

Within the SNMP management framework, the philosophy is to place the
burden of management processing on managers, not on agents.  As the
Internet evolves to accommodate multiple protocol suites, there may be
SNMP agents in the Internet that do not support the recommended method
of exchanging SNMP messages using UDP/IP. In these instances, the
proper model for managing a multiprotocol internet should be that
agents must only be required to support one method of exchanging SNMP
messages (i.e., encapsulation of SNMP messages in *one* of the
protocol suites of the multi-protocol internet), and the managers
support as many encapsulation methods as needed (potentially, all) to
communicate with all resources it manages.

The SNMP over a Multi-protocol Internet Working Group is chartered to identify
and provide solutions for communication between SNMP agents and
managers in those configurations where the recommended method of
exchanging SNMP messages using UDP/IP cannot be used; i.e., where a
managed resource supports a single protocol suite that protocol is not
UDP/IP but another protocol suite of the multi-protocol internet (for
example, OSI, AppleTalk, or XNS/IPX).

Questions to be considered include: What are the appropriate protocol
suites to consider?  What is the appropriate method of encapsulating
SNMP?  What are the addressing considerations for SNMP messages What
new MIB Modules are required?  What (positive) effect can SNMP-based
management have on resource-sharing among multiple protocols?


Goals and Milestones:

     Done Post an Internet-Draft describing operation of SNMP over OSI.

     Done Post an Internet-Draft describing operation of SNMP over IPX.

     Done Post an Internet-Draft describing operation of SNMP over Appletalk.

     Done Submit a document describing the operation of SNMP over OSI as a
          Proposed Standard.

     Done Submit a document describing the operation of SNMP over IPX as a
          Proposed Standard.

     Done Submit a document describing the operation of SNMP over Appletalk
          as a Proposed Standard.

Management Services Interface (msi)

Charter

Chair(s):
     Oscar Newkerk  <[e-mail]>
     Sudhanshu Verma  <[e-mail]>

Network Management Area Director(s)
     J.R. Davin  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Status: concluded

Description of Working Group:

The objective of the Management Services Interface Working Group is to
define a management services interface by which management
applications may obtain access to a heterogeneous, multi-vendor,
multi-protocol set of manageable objects.

The service interface is intended to support management protocols and
models defined by industry and international standards bodies.  As
this is an Internet Engineering Task Force Working Group, the natural
focus is on current and future network management protocols and models
used in the Internet.  However, the interface being defined is
expected to be sufficiently flexible and extensible to allow support
for other protocols and other classes of manageable objects.  The
anticipated list of protocols includes Simple Network Management
Protocol (SNMP), OSI Common Management Information Protocol (CMIP),
CMIP Over TCP (CMOT), Manufacturing Automation Protocol and Technical
Office Protocol CMIP (MAP/TOP CMIP) and Remote Procedure Call (RPC).

Goals and Milestones:

     Done Initial version of the Internet Draft placed in the Internet-Drafts
          directory

     Done Revised version of the draft from editing meetings placed in the
          Internet-Drafts directory

   Aug 90 Initial implementation of the prototype available for test.

     Done  Revised draft based on the implementation experience submitted to
          the RFC editor.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  None to date.
IP MTU Discovery (mtudisc)

Charter

Chair(s):
     Jeff Mogul  <[e-mail]>

Internet Area Director(s)
     Philip Almquist  <[e-mail]>
     Stev Knowles  <[e-mail]>
     Dave Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Status: dormant

Description of Working Group:

The MTU Discovery Working Group is chartered to produce an RFC
defining an official standard for an IP MTU Discovery Option.  ``MTU
Discovery'' is a process whereby an end-host discovers the smallest MTU
along a path over which it is sending datagrams, with the aim of
avoiding fragmentation.

Goals and Milestones:

     Done Decide if the proposal in RFC 1063 is sufficient, or if there are
          flaws to be corrected, or possible improvements to be made.  Or,
          decide that it is unwise to create an official standard.

  Ongoing Encourage the participation of gateway implementors, since the MTU
          discovery process affects the design and performance of IP gateways.

     Done Encourage sample implementations of end-host and gateway portions of
          MTU Discovery for popular software (BSD-derived kernels, primarily).
          Encourage rapid implementation by major gateway vendors, since this
          option is relatively useless without widespread support.

     Done Unless the proposal in RFC 1063 is acceptable, write a new RFC
          describing a different approach.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  RFC  Stat Published    Title
------- -- ---------- -----------------------------------------
RFC1191 PS   Nov 90     Path MTU Discovery
Network Access Server Requirements (nasreq)

Charter

Chair(s):
     Allan Rubens  <[e-mail]>
     John Vollbrecht  <[e-mail]>

Security Area Director(s)
     Steve Crocker  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:


The Network Access Server Requirements Working Group has as its primary
goal, to identify functions and services that should be present in IP
Network Access Servers (NAS's) and to specify the standards that
provide for these functions and services.  The term ``Network Access
Server'' is used instead of the more conventional term ``Terminal Server''
as it more accurately describes the functions of interest to this
Group.  A ``Network Access Server'' is a device that provides for the
attachment of both traditional ``dumb terminals'' and terminal emulators
as well as workstations, PC's or routers utilizing a serial line
framing protocol such as PPP or SLIP.  A NAS is viewed as a device that
sits on the boundary of an IP network, providing serial line points of
attachment to the network.  A NAS is not necessarily a separate
physical entity; for example, a host system supporting serial line
attachments is viewed as providing NAS functionality and should abide
by NAS requirements.

This Group will adopt (or define, if need be) a set of standard
protocols to meet the needs of organizations providing network access.
The immediate needs to be addressed by the Group are in the areas of
authentication, authorization, and accounting (AAA). In general, this
Group will select a set of existing standards as requirements for a
NAS.  If necessary, the Group will identify areas of need where
internet standards don't already exist and new standardization efforts
may be required.

Initially the Group will independently investigate the two cases of
character and frame oriented access to the NAS.  This investigation
will be aimed at determining what work is being done, or needs to be
done, in this and other working groups in order to be able to define
the set of NAS requirements.  While the ultimate goal of this Group is
to produce a NAS Requirements document, it may be necessary to define
standards as well.  This initial investigation will help determine what
the goals of this Group need to be.  The Group will also work with
appropriate Working Groups to define required NAS standards that fall
into the areas of these other groups.


Goals and Milestones:

     Done NAS Requirements Document posted as an Internet-Draft.

   Nov 92 Post an Internet-Draft on Character oriented Authentication,
          Authorization, and Accounting(AAA).

   Nov 92 Post an Internet-Draft on frame oriented AAA requirements.

   Nov 93 Submit the NAS Requirements document to the IESG as a Proposed
          Standard.

Network Database (netdata)

Charter

Chair(s):
     Daisy Shen  <[e-mail]>

Applications Area Director(s)
     Russ Hobby  <[e-mail]>
     Erik Huizer  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The Network Database Working Group is chartered to define a standard
interface among databases on TCP/IP networks.  The Working Group will
address the issue of database connectivity in a distributed environment
which allows authorized users remote access to databases.  It will be
designed as a client/server model based on TCP/IP as its communication
protocol.

Several problems must be resolved that are associated with the network
database protocol, such as management of multiple threads between
clients and servers, management of multiple servers, management of data
buffers, data conversions, and security.

Additional related problems will be covered as the discussion goes on.
Therefore, the description and the schedule can be revised.

This Working Group is independent from the SQL access group; however,
there may be some overlapping interest.  The SQL access group is welcome
to join IETF's discussions and share information in both directions.
If both groups find that merging two efforts into one will speed up the
process, the merge can be done in the future.  For now, this Working
Group works on issues according to its own schedule and efforts.


Goals and Milestones:

     Done Review and approve the Charter, making any changes necessary.
          Examine needs, resources for this network database protocol
          and define the scope of work. Begin work on a framework for the
          solution.  Assign writing assignments for first draft of the
          document.

     Done First draft to be completed.

     Done Review first draft document, determine necessary revisions.
          Discuss problems remained unsolved from the first IETF meeting.

     Done Continue revisions based on comments received at meeting and
          e-mail.  Start making document an Internet-Draft.

   Mar 92 Review final draft.  If it is OK, give it to IESG for publication
          as RFC.

   Jun 92 Revise document based on implementations.  Ask IESG to make
          the revision a Draft Standard.

Network Fax (netfax)

Charter

Chair(s):
     Mark Needleman  <[e-mail]>

Applications Area Director(s)
     Russ Hobby  <[e-mail]>
     Erik Huizer  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           /pub/[e-mail]

Status: concluded

Description of Working Group:


The Network Fax Working Group is chartered to explore issues
involved with the transmission and receipt of facsimilies across TCP/IP
networks and to develop recommended standards for facsimile
transmission across the Internet.  The Group is also intended to serve
as a coordinating forum for people doing experimentation in this area
to attempt to maximize the possibility for interoperability among
network fax projects.

Among the issues that need to be resolved are what actual
protocol(s) will be used to do the actual data transmission
between hosts, architectural models for the integration of fax
machines into the existing internet, what types of data encoding
should be supported, how IP host address to phone number conversion
should be done and associated issues of routing, and development of a
gateway system that will allow existing Group 3 and Group 4 fax
machines to operate in a network environment.

It is expected that the output of the Working Group will be one
or more RFC's documenting recommended solutions to the above questions
and possibly also describing some actual implementations.  The life of
the Working Group is expected to be 18-24 months.

It is also hoped that some fax vendors, as well as the
networking community and fax gateway developers, will be brought into
the effort.



Goals and Milestones:

     Done Review  and  approve Charter  making  any  changes deemed necessary.
          Refine definition of scope of  work  to  be  accomplished  and
          initial set of RFC's to be developed.  Begin working on
          framework for solution.

     Done Continue work  on  definition  of issues  and protocols.
          Work to be conducted on mailing  list.

     Done First  draft  of  RFC  to be completed.  To be discussed at IETF
          meeting and revised as necessary.

     Done Continue revisions based  on comments   received   and   submit
          to  IESG  for  publication as RFC.

   Mar 92 Overlapping  with  activities listed above may be implementations
          based on ideas  and  work  done  by the Working Group.  If so revise
          RFC to include knowledge gained from such implementations.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  RFC  Stat Published    Title
------- -- ---------- -----------------------------------------
RFC1314 PS   Apr 92     A File Format for the Exchange of Images in the
                        Internet
Networked Information Retrieval (nir)

Charter

Chair(s):
     Jill Foster  <[e-mail]>
     George Brett  <[e-mail]>

User Services Area Director(s)
     Joyce Reynolds  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           archives.cc.mcgill.ca:~/pub/mailing-lists/nir

Description of Working Group:

As the network has grown, along with it there has been an increase in
the number of software tools and applications to navigate the network
and make use of the many, varied resources which are part of the
network.  Within the past year and a half we have seen a wide spread
adoption of tools such as the ARCHIE servers, the Wide Area Information
Servers (WAIS), the Internet Gopher, and the WorldWide Web (WWW).  In
addition to the acceptance of these tools there are also diverse
efforts to enhance and customize these tools to meet the needs of
particular network communities.

There are many organizations and associations that have recently begun
to focus on the proliferating resources and tools for networked
information retrieval (NIR).  The Networked Information Retrieval Group
will be a cooperative effort of three major players in the field of
NIR: IETF, RARE, and the Coalition for Networked Information (CNI)
specifically tasked to collect and disseminate information about the
tools and to discuss and encourage cooperative development of current
and future tools.

The NIR Working Group intends to increase the useful base of
information about networked information retrieval (NIR) tools, their
developers, interested organizations, and other activities that relate
to the production, dissemination, and support of NIR tools, to produce
documentation that will enable user services organizations to provide
better support for NIRtools, to develop materials that will assist the
support and training of end users and to evolve in the future as
necessary to meet and anticipate changes in the field (i.e., NIR
tools, protocols, network topology, etc.)

Goals and Milestones:

     Done Review and comment on proposed charter.  Discuss Applications
          Template and Organizational Template.

   Sep 92 Post an Internet-Draft containing the Applications and Organizational
          Templates.

   Oct 92 Post an Internet-Draft of the ``Consumer Report'' with introductory
          material and completed templates.

   Dec 92 Submit ``Consumer Report'' to the IESG for publication as an
          Informational RFC.

Network Information Services Infrastructure (nisi)

Charter

Chair(s):
     April Marine  <[e-mail]>
     Pat Smith  <[e-mail]>

User Services Area Director(s)
     Joyce Reynolds  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The NISI Working Group will explore the requirements for common, shared
Internet-wide network information services. The goal is to develop an
understanding for what is required to implement an information services
``infrastructure'' for the Internet.  The work will begin with existing NIC
functions and services and should build upon work already being done within the
Internet community.  It should address areas such as common information
formats, methods of access, user interface, and issues relating to security and
privacy of Internet databases.


Goals and Milestones:

     Done Complete draft for phase 2 suggesting cooperative agreements for
          NICs.

     Done Review draft for phase 1 and begin discussions for completing the
          second phase which is to define a basic set of `cooperative
          agreements' which will allow NICs to work together more effectively
          to serve users.

     Done Revised draft document ready for Working Group review. Document
          defines NIC functions and suggests some standardizations for NIC
          services, as well as offers new mechanisms for exchanging information
          between NICs.

     Done Document submitted as Internet-Draft for comment from a wider
          Internet audience.

     Done Working Group discussed current Internet-Draft and suggested minor
          revisions. Decision made to continue Working Group activity beyond
          this document.

     Done First document released as informational RFC. Outline and discuss new
          NISI tasks at IETF meeting.

     Done Write a document explaining the security issues of privacy and
          accuracy in Internet databases. Publish as an informational RFC.

Network Joint Management (njm)

Charter

Chair(s):
     Gene Hastings  <[e-mail]>

Operational Requirements Area Director(s)
     Phill Gross  <[e-mail]>
     Bernard Stockman  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

There is a need for many different kinds of efforts to deal with
operational and front line engineering issues, including helping the
disparate organizations work with each other.  This is an attempt to
solidify some of those topics.  This does not make any pretense of being
exhaustive.

Area of interest:  Operational issues and developments of the Internet.

Membership:  Operations and engineering personnel from national backbone
and mid-level networks.  Other groups with responsibility for production
oriented services such as security oriented groups.

Associated Technical groups:  Groups which will have an interest in, and
input to the Agenda of this Group will include the IAB and its task
forces, and groups within FARNET. In particular FARNET has now several
technical issues of concern, such as the selection of standard
inter-network services for debugging (like maps and standard SNMP
communities), and the specification of standard network statistics to be
taken (of special concern is the ubiquitous ability to collect those
statistics).

Meeting Times:  Members of the Group will represent organizations with
production responsiblities.  Most work will be carried on via email or
teleconferencing.

Goals and Milestones:

Network News Transport Protocol (nntp)

Charter

Chair(s):
     Eliot Lear  <[e-mail]>

Applications Area Director(s)
     Russ Hobby  <[e-mail]>
     Erik Huizer  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

This Group will study and review the issues involved with netnews
transport over the Internet.  Originally released as an RFC in
February of 1986, NNTP is one of the widest implementations of an
elective status protocol.  As of this writing, the protocol has just
passed its fifth birthday, not having been updated once.

Over the years several enhancements have been suggested, and several
have even been implemented widely.  The intent of this Working Group
will be to encode the more popular and plausible enhancements into an
Internet standard.  Included in the initial list of changes to be
considered are the following:

(1) User level and site designated authentication methods;
(2) Binary transfer capability;
(3) Minimization of line turnaround; and
(4) Stronger article selection capability.

It is expected that public domain software will be released
concurrently with an RFC, demonstrating the protocol enhancements.



Goals and Milestones:

     Done Define scope of work.

     Done Submit Internet-Draft for review and comment.

     Done Possibly meet at USENIX for further comment.

     Done Meet at IETF for further comment.

   Aug 91 Submit RFC to IESG.

NOC-Tool Catalogue Revisions (noctool2)

Charter

Chair(s):
     Robert Enger  <[e-mail]>
     Darren Kinley  <[e-mail]>

User Services Area Director(s)
     Joyce Reynolds  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The NOC-Tools Working Group will update and revise their catalog to
assist network managers in the selection and acquisition of diagnostic
and analytic tools for TCP/IP Internets.

- Update and revise the reference document that lists what tools are available,
  what they do, and where they can be obtained.

- Identify additional tools available to assist network managers in debugging
  and maintaining their networks that were inadvertently omitted in previous
  NOCTools catalog.

- Identify additional new or improved tools that have become apparent since the
  last compilation of the reference document.

- Arrange for the central (or multi-point) archiving of these tools in order to
  increase their availability.

- Establish procedures to ensure the ongoing maintenance of the reference and
  the archive, and identify an organization willing to do it.

Goals and Milestones:

     Done Review Internet tool needs and updates/corrections for the ``Son of
          NOCTools'' catalog. Discussion of additional input to the catalog.

     Done Draft of catalog will be prepared, draft to be reviewed
          and modified. Initiate IETF Internet-Draft review process by
          submission of a ``Son of NOCTools'' catalog draft to IESG Secretary.

     Done Follow-up with final amendments to the document and the submission of
          the catalog to RFC Editor as an FYI RFC for publication.

NOC-Tools (noctools)

Charter

Chair(s):
     Robert Enger  <[e-mail]>

User Services Area Director(s)
     Joyce Reynolds  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Status: concluded

Description of Working Group:

The NOC-Tools Working Group will develop a catalog to assist network
managers in the selection and acquisition of diagnostic and analytic
tools for TCP/IP Internets.

Goals and Milestones:

          Identify tools available to assist network managers in debugging and
          maintaining their networks.

          Publish a reference document listing what tools are available, what
          they do, and where they can be obtained.

          Arrange for the central (or multi-point) archiving of these tools in
          order to increase their availability.

          Establish procedures to ensure the ongoing maintenance of the
          reference and the archive, and identify an organization willing to do
          it.

          Identify the need for new or improved tools as may become apparent
          during the compilation of the reference document.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  RFC  Stat Published    Title
------- -- ---------- -----------------------------------------
RFC1147      Apr 90     FYI on a Network Management Tool Catalog: Tools for
                        Monitoring and Debugging TCP/IP Internets and
                        Interconnected Devices
Network OSI Operations (noop)

Charter

Chair(s):
     Susan Hares  <[e-mail]>
     Cathy Wittbrodt  <[e-mail]>

Operational Requirements Area Director(s)
     Phill Gross  <[e-mail]>
     Bernard Stockman  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           merit.edu:~/pub/noop-archive

Description of Working Group:

The Working Group is chartered to work on issues related to the
deployment of CLNP in the Internet.  The first area of this Group's
work has been the learning necessary to start deploying OSI in
internet networks.  This phase includes planning for OSI
deployment by creating routing plans for regional networks and
education on using OSI routing protocols.

This first area of the Group's work will be on-going as we continue to
deploy OSI in the Internet.  This step has lead to people deploying
OSI for Pilot projects and demonstrations of OSI.

The second step of deploying OSI will be the transition of OSI from a
pilot service to a production service.  During this phase we will work
on specifying the network debugging tools and test beds.  We will need
to track the level of OSI support in the Internet.  We will need to
provide documentation for new users of OSI on the Internet.


Goals and Milestones:

  Ongoing Provide a forum to discuss OSI routing plans by email or in group
          discussions.

   Jan 92 Post as an Internet-Draft, a tutorial for CLNP OSI routing protocols,
          including ES-IS, CLNP, IS-IS, and IDRP.

   Apr 92 Post as an Internet-Draft, a requirements document specifying what
          OSI network tools are needed on every host and router.

   Jul 92 Post as an Internet-Draft, a collection of regional Routing and
          Addressing plans.

     Done Post as an Internet-Draft, a list of OSI Network Utilities available
          in the public domain and from vendors.  This list will be passed over
          to the NOC tools Group effort for joint publication.

   Jul 92 Post as an Internet-Draft, a description of OSI network layer
          debugging methods.

     Done Post as an Internet-Draft, a list of OSI Network Layer NOC tools
          available in the public domain and from vendors.  This list will be
          passed over to the NOC tools Group effort for joint publication.

   Jul 92 Submit to the IESG for Proposed Standard, a requirements document
          specifying what network tools are needed on every OSI host and
          router.

   Aug 92 Submit to the IESG as an Informational RFC, a description of OSI
          network layer debugging methods.

Network Printing Protocol (npp)

Charter

Chair(s):
     Glenn Trewitt  <[e-mail]>

Applications Area Director(s)
     Russ Hobby  <[e-mail]>
     Erik Huizer  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The Network Printing Working Group has the goal of pursuing those
issues which will facilitate the use of printers in an internetworking
environment.  In pursuit of this goal it is expected that we will
present one or more printing protocols to be considered as standards
in the Internet community.

This Working Group has a number of specific objectives.  To provide a
draft RFC which will describe the LPR protocol.  To describe printing
specific issues on topics currently under discussion within other
Working Groups (e.g., Security and Dynamic Host Configuration), to
present our concerns to those Working Groups, and to examine printing
protocols which exist or are currently under development and assess
their applicability to Internet-wide use, suggesting changes if
necessary.


Goals and Milestones:

     Done Review and approve the Charter, making any changes deemed necessary.
          Review the problems of printing in the Internet.

     Done Write draft LPR specification.

     Done Discuss and review the draft LPR specification.  Discuss long-range
          printing issues in the Internet. Review status of Palladium print
          system at Project Athena.

     Done Submit final LPR specification including changes suggested at the May
          IETF.  Discuss document on mailing list.

     Done Submit LPR specification as an RFC and standard.

   Jul 90 Write description of the Palladium printing protocol (2.0) in RFC
          format.

   Aug 90 Discuss and review the draft Palladium RFC.

Office Document Architecture (oda)

Charter

Chair(s):
     Peter Kirstein  <[e-mail]>

Applications Area Director(s)
     Russ Hobby  <[e-mail]>
     Erik Huizer  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The ODA Working Group will develop guidelines for the use of the Office
Document Architecture for the  exchange of Compound documents including
formattable text, bit-map graphics and geometric graphics according to
the ODA Standard.  It will  consider  also Intercept Standards for other
document  content types it considers vital - e.g.,  spreadsheets.  The
Working Group will  define  how to use  both SMTP and X.400  for
interchange of ODA documents.   It will maintain close liaison with the SMTP
and X.400 Working Groups.

This Working Group will review the availability of ODA implementations, in
order to mount a Pilot Testbed for processable compound document
interchange.  Finally, it will set up and evaluate such a testbed.



Goals and Milestones:

  Ongoing Coordinate ODA Pilot.

  Ongoing Review and propose additional enhancements of ODA.

     Done Inaugural meeting.

     Done Produce a paper stating  what ODA standards  or profiles still
          need completing.

     Done Produce paper on what pilot implementations can be provided.

   Jul 91 Produce paper on what scale and type of Pilot Testbed should be
          organised.

   Jun 92 Provide first feedback on the ODA Pilot.

OSI Internet Management (oim)

Charter

Chair(s):
     Lee LaBarre  <[e-mail]>
     Brian Handspicker  <[e-mail]>

Network Management Area Director(s)
     J.R. Davin  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Status: concluded

Description of Working Group:

This Working Group will specify management information and protocols
necessary to manage IP-based and OSI-based LANs and WANs in the
Internet based on OSI Management standards and drafts, NIST
Implementors Agreements and NMF Recommendations. It will also provide
input to ANSI, ISO, NIST and NMF based on experience in the Internet,
and thereby influence the final form of OSI International Standards on
management.


Goals and Milestones:

          Develop implementors agreements for implementation of CMIP over TCP
          and CMIP over OSI.

          Develop extensions to common IETF SMI to satisfy requirements for
          management of the Internet using OSI management models and protocols.

          Develop extensions to common IETF MIB-II to satisfy requirements for
          management of the Internet using OSI management models and protocols.

          Develop prototype implementations based on protocol implementors
          agreements, IETF OIM Extended SMI and Extended MIB.

          Promote development of products based on OIM agreements.

          Provide input to the ANSI, ISO, NIST and NMF to influence development
          of OSI standards and implementors agreements.

          Completion of the following drafts: Implementors Agreements, Event
          Management, SMI Extensions, MIB Extensions, OSI Management Overview,
          Guidelines for the Definition of Internet Managed Objects.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  RFC  Stat Published    Title
------- -- ---------- -----------------------------------------
RFC1095 DS   Apr 89     Common Management Information Services and Protocol
                        over TCP/IP CMOT

RFC1214 PS   Apr 91     OSI Internet Management: Management Information Base
Operational Statistics (opstat)

Charter

Chair(s):
     Bernhard Stockman  <[e-mail]>
     Phillip Gross  <[e-mail]>

Operational Requirements Area Director(s)
     Phill Gross  <[e-mail]>
     Bernard Stockman  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

Today  there exist a  variety of network  management tools for
the collection and presentation  of network statistical  data.
Different kinds  of measurements  and  presentation techniques
makes it hard to compare data between networks.  There exists a
need to compare these statistical data on  a uniform  basis to
facilitate cooperative management,  ease problem isolation  and
network planning.

The Working Group will  try  to   define a  model for  network
statistics,   a minimal set   of  common  metrics,   tools for
gathering  statistical  data, a  common  statistical  database
storage format and  common presentation   formats.  Collecting
tools will store data in a given  format later to be retrieved
by presentation tools displaying the data in a predefined way.


Goals and Milestones:

     Done Agreement on a model.

     Done Survey for most useful and popular metrics.

     Done Survey for most useful and popular presentation formats.

   Dec 90 Identify similar efforts being performed by other groups.

     Done Define a common minimal set of metrics.

   Mar 91 Propose a MIB for metrics not already there.

     Done Define a common storage format to facilitate data sharing.

     Done Define common presentation formats to make data comparable.

   Mar 91 Develop outline, and make writing assignments for paper (Opstat1)
          documenting March 1991 milestones.

   May 91 Complete paper Opstat1.

   May 91 Possible mid-term meeting to review Opstat1.

   May 91 Submit Opstat1 as Internet-Draft.

   Jul 91 Approve paper Opstat1 for submission as RFC; decide
          standards-track or Informational?

   Jul 91 Define a new collection of tools based on defined metrics, defined
          storage formats and defined presentation formats.

   Jul 91 Propose old tools to be retrofitted.

   Jul 91 Develop outline and make writing assignments for paper (Opstat2) on
          new tools and retrofitted tools.

   Sep 91 Complete paper Opstat2.

   Sep 91 Possible mid-term meeting to review Opstat2.

   Sep 91 Submit Opstat2 as Internet-Draft.

   Dec 91 Approve paper Opstat2 for submission as RFC; decide
          standards-track or Informational?

Operational Requirements Area Directorate (orad)

Charter

Chair(s):
     Bernhard Stockman  <[e-mail]>
     Philip Gross  <[e-mail]>

Operational Requirements Area Director(s)
     Phill Gross  <[e-mail]>
     Bernard Stockman  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

No description available

Goals and Milestones:

OSI Directory Services (osids)

Charter

Chair(s):
     Steve Hardcastle-Kille  <[e-mail]>

Applications Area Director(s)
     Russ Hobby  <[e-mail]>
     Erik Huizer  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The OSI-DS Group works on issues relating to building an OSI Directory
Service using X.500 and its deployment on the Internet.  Whilst this
Group is not directly concerned with piloting, the focus is practical,
and technical work needed as a pre-requisite to deployment of an open
Directory will be considered.

Goals and Milestones:

  Ongoing Maintain a Schema for the OSI Directory on the Internet.

  Ongoing Liaisons should be established as appropriate.  In
          particular:  RARE WG3, NIST, CCITT/ISO IEC, North American
          Directory Forum.

     Done Definition of a Technical Framework for Provision of a Directory
          Infrastructure on the Internet, using X.500.  This task may later be
          broken into subtasks.  A series of RFCs will be produced.

     Done Study the relationship of the OSI Directory to the Domain
          Name Service.

OSI General (osigen)

Charter

Chair(s):
     Robert Hagens  <[e-mail]>
     Ross Callon  <[e-mail]>

OSI Integration Area Director(s)
        <>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           janeb.cs.wisc.edu:/pub/archives/ietf-osi

Status: concluded

Description of Working Group:

Help facilitate the incorporation of the OSI protocol suite into the
Internet, to operate in parallel with the TCP/IP protocol suite.
Facilitate the co-existence and interoperability of the TCP/IP and OSI
protocol suites.

Goals and Milestones:

     Done Specify an addressing format (from those available from the OSI NSAP
          addressing structure) for use in the Internet.  Coordinate addressing
          format with GOSIP version 2 and possibly other groups.

          Review the OSI protocol mechanisms proposed for the upcoming Berkeley
          release 4.4.  Coordinate efforts with Berkeley.

          Review GOSIP. Open liaison with Government OSI Users Group (GOSIUG)
          for feedback of issues and concerns that we may discover.

          Determine what should be used short-term for
          (i) intra-domain routing; and (ii) inter-domain routing.

          For interoperability between OSI end systems and TCP/IP end systems,
          there will need to be application layer gateways.  Determine if there
          are any outstanding issues here.

          Review short-term issues involved in adding OSI gateways to the
          Internet.  Preferably, this should allow OSI and/or dual gateways to
          be present by the time that Berkeley release 4.4 comes out.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  RFC  Stat Published    Title
------- -- ---------- -----------------------------------------
RFC1139 PS   Jan 90     Echo function for ISO 8473
Assignment of OSI NSAP Addresses (osinsap)

Charter

Chair(s):
     Richard Colella  <[e-mail]>

OSI Integration Area Director(s)
        <>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Status: concluded

Description of Working Group:

The OSI NSAP Guidelines Working Group will develop guidelines for NSAP
assignment and administration (AKA, the care and feeding of your NSAPs).

Assuming use of existing NSAP address standards, there are two
questions facing an administration:

\begin{itemize}

\item
 Do I want to be an administrative authority for allocating NSAPs?
    \begin{itemize}
    \item
        how do I become an administrative authority?
        \begin{itemize}
        \item
          what organizations should expect to be an ``administrative
            authority'' in the GOSIP version 2.0 address structure?
        \item
          where do I go to become an administrative authority?
        \end{itemize}
    \item
        what are the administrative responsibilities involved?
        \begin{itemize}
        \item
           defining and implementing assignment procedures?
        \item
          maintaining the register of NSAP assignments.
        \item
        what are the advantages/disadvantages of being an
         administrative authority?
        \end{itemize}
    \end{itemize}
\item
 Whether NSAPS are allocated from my own or some other
     administrative authority, what are the technical implications of
     allocating the substructure of NSAPs?

    \begin{itemize}
    \item
        what should be routing domains?
        \begin{itemize}
        \item
          implications of being a separate routing domain (how it will
            affect routes, optimality of routes, firewalls and
            information hiding).
        \item
          organizing routing domains by geography versus by
            organization versus by network topology....
        \end{itemize}
    \item
       within any routing domain, how should areas be configured?

        \begin{itemize}
        \item
         (same implications as above).
        \end{itemize}
    \end{itemize}
\end{itemize}

Goals and Milestones:

     Done Have the paper published as an RFC.

     Done Produce a paper describing guidelines for the acquisition and
          administration of NSAP addresses in the Internet.

   Dec 90 Have the paper incorporated, in whole or in part, into the ``GOSIP
          User Guide'' and the FNC OSI Planning Group document.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  RFC  Stat Published    Title
------- -- ---------- -----------------------------------------
RFC1237 PS   Jul 91     Guidelines for OSI NSAP Allocation in the Internet
OSI X.400 (osix400)

Charter

Chair(s):
     Rob Hagens  <[e-mail]>

OSI Integration Area Director(s)
        <>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           janeb.cs.wisc.edu:/pub/archives/ietf-osi-x400

Status: concluded

Description of Working Group:

The IETF OSI X.400 Working Group is chartered to identify and provide
solutions for problems encountered when operating X.400 in a dual
protocol internet.  This Charter includes pure X.400 operational
issues as well as X.400 $<$-$>$ RFC 822 gateway (ala RFC 987) issues.

Goals and Milestones:

   Jul 90 Develop a scheme to alleviate the need for static RFC 987 mapping
          tables.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  None to date.
Open Shortest Path First IGP (ospf)

Charter

Chair(s):
     Mike Petry  <[e-mail]>
     John Moy  <[e-mail]>

Routing Area Director(s)
     Bob Hinden  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The OSPF Working Group will develop and field test an SPF-based
Internal Gateway Protocol.  The specification will be published and
written in such a way so as to encourage multiple vendor
implementations.

Goals and Milestones:

     Done Design the routing protocol, and write its specification.

     Done Develop multiple implementations, and test against each other.

     Done Obtain performance data for the protocol.

     Done Make changes to the specification (if necessary) and publish the
          protocol as a Draft Standard RFC.

          Gather operational experience with the OSPF protocol and submit the
          document as a Standard.

Private Data Network Routing (pdnrout)

Charter

Chair(s):
     CH Rokitansky  <[e-mail]>

Routing Area Director(s)
     Bob Hinden  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Status: concluded

Description of Working Group:

The DoD INTERNET TCP/IP protocol suite has developed into a de facto
industry standard for heterogenous packet switching computer networks.
In the US, several hundreds of INTERNET networks are connected
together; however the situation is completely different in Europe.

\vspace{.15in}
The only network which could be used as a backbone to allow
interoperation between the many local area networks in Europe, now
subscribing to the DoD INTERNET TCP/IP protocol suite, would be the
system of Public Data Networks (PDN). However, so far, no algorithms
have been provided to dynamically route INTERNET datagrams through
X.25 public data networks.  Therefore, the goals of the Public Data
Network Routing Working Group are the development, definition and
specification of required routing and gateway algorithms for an
improved routing of INTERNET datagrams through the system of X.25
Public Data Networks (PDN) to allow worldwide interoperation between
TCP/IP networks in various countries.  In addition, the application
and/or modification of the developed algorithms to interconnect local
TCP/IP networks via ISDN (Integrated Services Digital Network) will be
considered.

Goals and Milestones:

     Done Application of the INTERNET Cluster Addressing Scheme to Public Data
          Networks.

     Done Development of hierarchical VAN-gateway algorithms for worldwide
          INTERNET network reachability information exchange between
          VAN-gateways.

     Done Assignment of INTERNET/PDN-cluster network numbers to national public
          data networks. (Mapping between INTERNET network numbers and X.121
          Data Network Identification Codes (DNICs)).

     Done Assignment of INTERNET/PDN-cluster addresses to PDN-hosts and
          VAN-gateways according to the developed hierarchical VAN-gateway
          algorithms.

     Done Definition of the PDN-cluster addressing scheme as an Internet
          standard.

     Done Delayed TCP/IP header compression by VAN-gateways and PDN-hosts.

     Done Provide a testbed for worldwide interoperability between local TCP/IP
          networks via the system of X.25 public data networks (PDN).

     Done Implementation of the required algorithms and protocols in a VAN-Box.

     Done Interoperability between ISO/OSI hosts on TCP/IP networks through
          PDN.

     Done Consideration of INTERNET Route Servers.

     Done Interoperability between local TCP/IP networks via ISDN.

     Done Development of Internetwork Management Protocols for worldwide
          cooperation and coordination of network control and network
          information centers.

     Done Specification of an X.121 Address resolution protocol.

     Done Specification of an X.25 Call Setup and Charging Determination
          Protocol.

     Done Specification of an X.25 Access and Forwarding Control Scheme.

     Done Specification of routing metrics taking X.25 charges into account.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  None to date.
Privacy-Enhanced Electronic Mail (pem)

Charter

Chair(s):
     Stephen Kent  <[e-mail]>

Security Area Director(s)
     Steve Crocker  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           [e-mail]

Description of Working Group:

PEM is the outgrowth of work by the Privacy and Security
Research Group (PSRG) of the IRTF.  At the heart of PEM is a set of
procedures for transforming RFC 822 messages in such a fashion as to
provide integrity, data origin authenticity, and optionally,
confidentiality.  PEM may be employed with either symmetric or
asymmetric cryptographic key distribution mechanisms.  Because the
asymmetric (public-key) mechanisms are better suited to the large
scale, heterogeneously administered environment characteristic of the
Internet, to date only those mechanisms have been standardized.  The
standard form adopted by PEM is largely a profile of the CCITT X.509
(Directory Authentication Framework) recommendation.

PEM is defined by a series of documents.  The first in the
series defines the message processing procedures.  The second defines
the public-key certification system adopted for use with PEM.
The third provides definitions and identifiers for various
algorithms used by PEM.  The fourth defines message formats and conventions for
user registration, Certificate Revocation List (CRL) distribution,
etc.  (The first three of these were previously issued as RFCs 1113,
1114 and 1115.  All documents have been revised and are being issed
first as Internet Drafts.)


Goals and Milestones:

     Done Submit first, third, and fourth documents as Internet-Drafts.

  Ongoing Revise Proposed Standards and submit to IESG for consideration as
          Draft Standard, and repeat for consideration as Internet Standard.

     Done Submit second document as Internet-Draft.

     Done First IETF Working Group meeting to review Internet-Drafts.

     Done Submit revised Internet-Drafts based on comments received during
          Working Group meeting, from pem-dev mailing list, etc.

     Done Submit Internet-Drafts to IESG for consideration as Proposed
          Standards.

     Done Post an Internet Draft of the MIME/PEM Interaction specification.

   Apr 93 Submit the PEM/MIME Specification to the IESG for consideration as a
          Proposed Standard.

P. Internet Protocol (pip)

Charter

Chair(s):
     Paul Tsuchiya  <[e-mail]>

Internet Area Director(s)
     Philip Almquist  <[e-mail]>
     Stev Knowles  <[e-mail]>
     Dave Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           thumper.bellcore.com:~/pub/tsuchiya/pip-archive

Description of Working Group:

The PIP Working Group is chartered to develop an IPv7 proposal using
the basic ideas of Pip as described in the Pip overview.

Pip is designed on one hand to be very general, being able to handle
many routing/addressing/flow paradigms, but on the other hand to allow
for relatively fast forwarding.  Pip has the potential to allow for
better evolution of the internet.  In particular, it is hoped that we
will be able to advance routing, addressing, and flow techniques
without necessarily having to change hosts (once hosts are running
Pip).

While the Pip overview demonstrates a number of powerful mechanisms,
much work remains to be done to bring Pip to a full specification.
This work includes, but is not limited to: specifying the header
format; specifying a basic set of error messages (PCMP messages);
specifying the Pip forwarding rules; specifying host interface messages
(particularly the directory service query response); specifying rules
for host Pip header construction; specifying modifications to existing
protocols for use with Pip (BGP IV, OSPF, ARP, DNS, etc.); specifying
Pip MAX MTU Discovery techniques; and specifying a transition strategy
for Pip.

Over the near-term, the goal of the PIP Working Group will be to produce these
specifications and supporting documentation.  Over the long-term, up to
the point where Pip is definitively rejected as IPv7, it is expected
that the PIP Working Group will oversee implementations and testing of the Pip
specifications.

Except to the extent that the PIP Working Group modifies existing protocols for
operation with Pip, and to the extent that the PIP Working Group must be aware of routing/addressing/flow architectures to really make Pip general, the
PIP Working Group will not work on routing/addresing/flow architectures.


Goals and Milestones:

     Done Review and approval of the Charter for the PIP Working Group.

     Done Post as an Internet-Draft a description of the Pip Packet Format and
          Forwarding Engine, the Pip Control Message Protocol (PCMP), the Pip
          Host Interface Message Protocol, and the Pip MTU Discovery Protocol.

   Oct 92 Post as an Internet-Draft a description of the modifications to BGP
          IV for Pip, the Modifications to OSPF for Pip, the modifications to
          DNS for Pip, the modifications to ARP for Pip, the Address assignment
          in Pip, and the Pip transition strategy.

     Done Presentation and review of the PIP specification by the IESG.  If
          acceptable, the first Working Group meeting will be held.

Process for Organization of Internet Standards (poised)

Charter

Chair(s):
     Steve Crocker  <[e-mail]>

Not Assigned to an Area Director(s)
        <>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           cnri.reston.va.us:~/poised/current

Description of Working Group:

       The goal of this Working Group is to examine the Internet
       standards process and the responsibilities of the IAB, with
       attention to the relationship between the IAB and IETF/IESG.

       The need for this Working Group was suggested during discussions
       at the July 1992 IETF.  This led to a request from the Internet
       Society president to form such a Working Group.

       The Working Group will consider the following matters:

         1. Procedures for making appointments to the Internet
            Architecture Board.

         2. Procedures for resolving disagreements among IETF, IESG and
            IAB in matters pertaining to the Internet Standards.

         3. Methods for assuring that for any particular Internet
            Standard, procedures have been followed satisfactorily by all
            parties so that everyone with an interest has had a fair
            opportunity to be heard.


       The Working Group will begin with a review of the procedures for making
       IAB appointments as documented in RFC 1358 and a review of
       the standards-making process documented in RFC 1310.

       The Working Group has a goal of issuing a final report in time for IESG
       consideration and publication as an RFC before the ISOC Board Trustee's
       meeting in December 1992.  Given the compressed timescale, the Working
       Group will conduct most of its deliberations by electronic mail on the
       POISED Working Group mailing list.   There will also be a preliminary
       report and discussions at the November 1992 IETF meeting in Washington,
       DC.

       This will be a normal IETF Working Group, i.e., the mailing list and all
       discussions will be completely open.

Goals and Milestones:

     Done Review and approval of the Charter for the POISED Working Group.

     Done Gather initial set of issues and write a preliminary report.

   Oct 92 Post as an Internet-Draft the initial recommendations to the ISOC
          Board.

     Done Open discussion and presentation of the work of the POISED Working
          Group at Washington D.C. IETF meeting.

   Dec 92 Submit the recommendations document to the IESG for posting as an
          Informational RFC.  This document will be subsequently transmitted to
          the ISOC Board.

Point-to-Point Protocol Extensions (pppext)

Charter

Chair(s):
     Brian Lloyd  <[e-mail]>

Internet Area Director(s)
     Philip Almquist  <[e-mail]>
     Stev Knowles  <[e-mail]>
     Dave Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The Point-to-Point Protocol (PPP) was designed to encapsulate multiple
protocols.  IP was the only network layer protocol defined in the
original documents.  The Working Group is defining the use of other
network level protocols and options for PPP. The Group will define the
use of protocols including: bridging, ISO, DECNET (Phase IV and V),
XNS, and others.  In addition it will define new PPP options for the
existing protocol definitions, such as stronger authentication and
encryption methods.

Goals and Milestones:

Router Discovery (rdisc)

Charter

Chair(s):
     Steve Deering  <>

Internet Area Director(s)
     Philip Almquist  <[e-mail]>
     Stev Knowles  <[e-mail]>
     Dave Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Status: concluded

Description of Working Group:

The Router Discovery Working Group is chartered to adopt or develop a
protocol that Internet hosts may use to dynamically discover the
addresses of operational neighboring gateways.  The group is expected
to propose its chosen protocol as a standard for gateway discovery in
the Internet.

The work of this group is distinguished from that of the Host
Configuration Working Group in that this group is concerned with the
dynamic tracking of router availability by hosts rather than the
initialization of various pieces of host state (which might include
router addresses) at host-startup time.


Goals and Milestones:

  Ongoing Gather implementation and operational experience, revise the
          specification to reflect lessons learned, and submit the protocol for
          Draft Standard.

     Done Created Working Group; established and advertised mailing list.
          Initiated email discussion to identify existing and proposed
          protocols, for router discovery.

     Done Held first meeting in Palo Alto.  Reviewed 9 candidate protocols, and
          agreed on a hybrid of cisco's GDP and an ICMP extension proposed by
          Deering.

     Done Held second meeting in Tallahassee.  Reviewed the proposed protocol
          and discussed a number of open issues.

     Done Held third meeting in Pittsburgh.  Discussed and resolved several
          issues that had been raised by email since the last meeting.  Draft
          specification of router discovery protocol to be ready by next
          meeting. Experimental implementations to be started.

     Done Meet in Vancouver.  Review draft specification, and determine any
          needed revisions.  Evaluate results of experimental implementations
          and assign responsibility for additional experiments, as required.
          Submit the specification for publication as a Proposed Standard
          shortly after the meeting.

     Done Revise specification as necessary, based on field experience.  Ask
          the IESG to elevate the protocol to Draft Standard status.  Disband.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  RFC  Stat Published    Title
------- -- ---------- -----------------------------------------
RFC1256 PS   Sep 91     ICMP Router Discovery Messages
RIP Version II (ripv2)

Charter

Chair(s):
     Gary Malkin  <[e-mail]>

Routing Area Director(s)
     Bob Hinden  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           xylogics.com:gmalkin/rip/rip-arc

Status: concluded

Description of Working Group:

The RIP Version 2 Working Group is chartered to expand the RIP protocol, as
defined in RFC 1058.  The expansion will include the addition of
subnet masks to the routing entries.  The expansion may also include
authentication, AS numbers, next hop address, MTU, or linkspeed.
Since all routing protocols are required to have a MIB, one will be
defined.  The primary issue is the maintainance of backwards
compatibility, which must be preserved.

The purpose of improving RIP is to make a simple, widely available
protocol more useful.  It is not intended that RIP-II be used in
places where OSPF would be far better suited.


Goals and Milestones:

          Given successful implementation experience, advancement of RIP-II to
          Draft Standard.  Submission of MIB into the standards track.

          Final meeting to achieve closure on any pending issues.

     Done Review of RIP-II Internet-Draft to ensure the additions are useful
          and backwards compatible.  Also ensure that the additions cannot
          cause routing problems.

     Done Final review of RIP-II Internet-Draft and submission into the
          standards track.  First review of RIP-II MIB.

     Done Review of implementations.  Final review of MIB.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  RFC  Stat Published    Title
------- -- ---------- -----------------------------------------
RFC1387      Jan 93     RIP Version 2 Protocol Analysis

RFC1388 PS   Jan 93     RIP Version 2 Carrying Additional Information

RFC1389 PS   Jan 93     RIP Version 2 MIB Extension
Remote LAN Monitoring (rmonmib)

Charter

Chair(s):
     Mike Erlinger  <>

Network Management Area Director(s)
     J.R. Davin  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Status: concluded

Description of Working Group:

    The LAN Monitoring MIB Working Group is chartered to define an
experimental MIB for monitoring LANs.

    The Working Group must first decide what it covers and what
terminology to use.  The initial thought was to investigate the
characteristics of some of the currently available products (Novell's
LANtern, HP's LanProbe, and Network General's Watch Dog).  From this
investigation MIB variables will be defined.  In accomplishing our
goals several areas will be addressed.  These include: identification
of the objects to place in the MIB, identification of the tree
structure and corresponding Object ID's for the MIB elements,
generation of the ASN.1 for these new elements, and a test
implementation.


Goals and Milestones:

     Done Mailing list discussion of Charter and collection of concerns.

     Done Discussion and final approval of Charter; discussion and agreement
          on models and terminology.  Make writing assignments.

     Done Discussion of the first draft document.  Begin work on  additional
          drafts if needed.

   Mar 91 Review latest draft of the first document and if  OK give to IESG for
          publication as an RFC.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  RFC  Stat Published    Title
------- -- ---------- -----------------------------------------
RFC1271 PS   Nov 91     Remote Network Monitoring Management Information Base
Router Requirements (rreq)

Charter

Chair(s):
     Philip Almquist  <[e-mail]>

Internet Area Director(s)
     Philip Almquist  <[e-mail]>
     Stev Knowles  <[e-mail]>
     Dave Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The Router Requirements Working Group has the goal of rewriting
the existing Router Requirements RFC, RFC-1009, and a) bringing
it up to the organizational and requirement explicitness levels
of the Host Requirements RFC's, as well as b) including
references to more recent work, such as OSPF and BGP.

The Working Group will also instigate, review, or (if appropriate)
produce additional RFCs on related topics.  To date, Group members have
produced draft documents discussing the operation of routers which are in
multiple routing domains (3 papers), TOS, and a routing table MIB.

The purposes of this project include:

- Defining what an IP router does in sufficient detail that
  routers from different vendors are truly interoperable.

- Providing guidance to vendors, implementors, and purchasers of
  IP routers.

The Working Group has decided that, unlike RFC-1009, the Router Requirements
document should not discuss Link Layer protocols or address resolution.
Instead, those topics should be covered in a separate Link Layer Requirements
document, applicable to hosts as well as routers.  Whether this Group will
create the Link Layer Requirements is still to be determined.


Goals and Milestones:

     Done First Internet-Draft version.

     Done Second Internet-Draft version.

     Done Third Internet-Draft version.

     Done Fourth Internet-Draft version.

   Oct 91 Final Internet-Draft version.

   Nov 91 Submission for Proposed Standard.

Special Host Requirements (shr)

Charter

Chair(s):
     Bob Stewart  <[e-mail]>

Internet Area Director(s)
     Philip Almquist  <[e-mail]>
     Stev Knowles  <[e-mail]>
     Dave Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Status: concluded

Description of Working Group:


        The Special-purpose Host Requirements Working Group is
chartered to clarify application of the Host Requirements RFCs (1122
and 1123) to systems that are technically hosts but are not intended
to support general network applications.  These special-purpose hosts
include, for example, terminal servers (a ``Telnet host''), or file
servers (an ``FTP host'' or an ``NFS host'').

        The Host Requirements RFCs address the typical,
general-purpose system with a variety of applications and an open
development environment, and give only passing consideration to
special-purpose hosts.  As a result, suppliers of special-purpose
hosts must bend the truth or make excuses when users evaluate their
products against the Requirements RFCs.  Users must then decide
whether such a product is in fact deficient or the requirements truly
do not apply.  This process creates work and confusion, and undermines
the value of the RFCs.  The commercial success of the Internet
protocols and their use in increasingly unsophisticated environments
exacerbates the problem.

        The Working Group must define principles and examples for
proper functional subsets of the general-purpose host and specifically
state how such subsets affect the requirements.  The Working Group
must determine the balance between an exhaustive list of specific
special-purpose hosts and philosphy that remains subject to debate.
For the most part, it should be possible to base decisions on existing
experience and implementations.  The special-purpose requirements will
be stated as differences from the existing RFCs, not replacements, and
will refer rather than stand alone.

        Since they define strict subsets of the Host Requirements
RFCs, the Special-purpose Host Requirements appear to be an easier job
and can be developed and stabilized within 8-12 months.  Most of the
Group's business can be conducted over the Internet through email.


Goals and Milestones:

   Jan 90 Revised document.

   Feb 90 Third IETF Meeting:  make document an Internet Draft. Continue
          revisions based on comments received at meeting and over e-mail.

     Done Mailing list discussion of Charter and collection of concerns.

     Done First IETF Meeting: discussion and final approval of Charter;
          discussion and agreement on approach, including models, format, level
          and type of detail.  Make writing assignments.

   Oct 90 First draft document.

   Nov 90 Second IETF Meeting:  review first draft document, determine
          necessary revisions.  Follow up discussion on mailing list.

   Apr 91 Final draft document.

   May 91 Fourth IETF meeting:  review final draft and if OK, give to IESG for
          publication as RFC.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  None to date.
Simple Internet Protocol (sip)

Charter

Chair(s):
     Christian Huitema  <[e-mail]>
     Steve Deering  <[e-mail]>

Internet Area Director(s)
     Philip Almquist  <[e-mail]>
     Stev Knowles  <[e-mail]>
     Dave Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

   SIP is another candidate for IPv7. The purpose of the Working Group
   is to finalize the SIP family of protocol, and to foster the early
   development and experimentation of this protocol.

   There are two major characteristics of the SIP proposal: it is very
   much a continuation of IP, and it aims at maximum simplicity. A
   short hand definition of SIP could be ``64 bits IP with useless
   overhead removed''.

   Following the IP model, SIP uses globally-unique addresses,
   hierarchically structured for efficient routing. SIP addresses are
   64 bits long, which we believe adequate to scale the Internet up
   to,  say, thousands of internet-addressable devices in every office,
   every residence, and every vehicle in the world.

   The quest of simplicity in SIP has been described as parallel to the
   RISC philosophy. The minimal SIP header contains only those fields
   which are necessary to achieve our goal: routing packets efficently
   in a very large internet. As a result of this design philosophy, the
   SIP header is much simpler than the IP header. Simplicity
   facilitates high-performance implementation and increases the
   likelihood of correct implementation.

   Contrary to several other IPv7 candidates, the SIP effort is
   focused mostly on the description of the final state, not on the
   description of the transition. This is due to a coordination with
   the IPAE working group, which has already engaged an intensive study
   of transition problems, with SIP in mind as a final state.

Goals and Milestones:

     Done Post the complete SIP specification as an Internet-Draft. This
          specification shall include the header format, the address format,
          ICMP and IGMP, the fragmentation protocol, the source route protocol,
          and the the requirements SIP imposes on higher layer protocols and
          lower later protocols, e.g., ARP.

   Jan 93 Post an Internet-Draft specifing the SIP addressing and routing
          architecture. Include discussion of multicast and mobile host support
          as well as a discussion of how policy routing can be supported.
          Detail the changes required to OSPF, BGP, and RIP.

   Jan 93 Post as an Internet-Draft a specification for the SIP MIB. Detail the
          operation of SNMP over SIP.

   Jan 93 Make available a public domain implementation of SIP for the UNIX-BSD
          socket environment.

   Jan 93 Make available a public domain version of modified TCP and UDP for
          the UNIX-BSD socket environment.

   Mar 93 Post as an Internet-Draft a report on the initial implementation and
          experience with SIP.

   Jun 93 Incorporate security into SIP.

   Jun 93 Specify in detail the changes to the routing protocols needed for
          SIP.

IP over Switched Megabit Data Service (smds)

Charter

Chair(s):
     George Clapp  <[e-mail]>
     Michael Fidler  <[e-mail]>

Internet Area Director(s)
     Philip Almquist  <[e-mail]>
     Stev Knowles  <[e-mail]>
     Dave Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           /ietf.mail.archives/ip-lpdn.mail.archive

Status: concluded

Description of Working Group:

The SMDS Working Group is chartered to investigate and to specify the
manner in which the Internet and the newly defined public network
service, Switched Multi-megabit Data Service, will interact.  The
group will discuss topics such as addressing, address resolution,
network management, and routing.

Goals and Milestones:

          Specify clearly an efficient interworking between the Internet and
          SMDS.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  RFC  Stat Published    Title
------- -- ---------- -----------------------------------------
RFC1209 DS   Mar 91     The Transmission of IP Datagrams over the SMDS Service
Internet Mail Extensions (smtpext)

Charter

Chair(s):
     John Klensin  <[e-mail]>
     Ned Freed  <[e-mail]>

Applications Area Director(s)
     Russ Hobby  <[e-mail]>
     Erik Huizer  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           dimacs.rutgers.edu:~/pub/ietf/*

Description of Working Group:

The SMTP Extensions Working Group is chartered to develop extensions to the
base SMTP protocol (RFC821) to facilitate the more efficient transmission of 8
bit text and binary data.  Among the extensions to be considered to SMTP are the
elimination of the ASCII text character restriction and line length restriction
to allow the sending of arbitrary 8 bit character sets, and the definition of
mechanisms to facilitate binary transmission, and extensions to the
negotiation sequence to facilitate batch transmission.


Goals and Milestones:

     Done Review the Charter of the Group.  Determine if changes to SMTP are
          necessary. Discuss the needs for backward compatability, and
          interoperability.  This discussion will be held by email.

     Done Discuss the elimination of the 7 bit restrictions in SMTP, and the
          implications of removing this restriction in terms of interoperation.

     Done Discuss the issues involved with binary transmission. Determine
          whether a ``binary'' mode should be pursued, and whether the SMTP
          line length restriction should be eliminated.

     Done Write a document specifying the changes to SMTP agreed to by the
          Group. Post as an Internet-Draft.

     Done Review and finalize the SMTP Extensions document.

     Done Submit the SMTP Extensions document as a Proposed Standard.

Simple Network Management Protocol (snmp)

Charter

Chair(s):
     Marshall Rose  <[e-mail]>

Network Management Area Director(s)
     J.R. Davin  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Status: concluded

Description of Working Group:

Oversee development of SNMP-related activity, especially the
Internet-standard SMI and MIB.  This Working Group is ultimately
responsible for providing workable solutions to the problems of
network management for the Internet community.



Goals and Milestones:

  Ongoing Coordinate the development of various experimental MIBs.

   Aug 90 Finish SNMP Authorization draft.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  RFC  Stat Published    Title
------- -- ---------- -----------------------------------------
RFC1155  S   May 90     Structure and Identification of Management Information
                        for TCP/IP-based Internets

RFC1157  S   May 90     A Simple Network Management Protocol (SNMP)

RFC1156  S   May 90     Management Information Base for Network Management of
                        TCP/IP-based internets

RFC1158 PS   May 90     Management Information Base for Network Management of
                        TCP/IP-based internets:  MIB-II

RFC1161 E    Jun 90     SNMP over OSI

RFC1162      Jun 90     Connectionless Network Protocol (ISO 8473) and End
                        System to Intermediate System (ISO 9542) Management
                        Information Base

RFC1212  S   Mar 91     Concise MIB Definitions

RFC1213  S   Mar 91     Management Information Base for Network Management of
                        TCP/IP-based internets: MIB-II

RFC1215      Mar 91     A Convention for Defining Traps for use with the SNMP

RFC1229 PS   May 91     Extensions to the Generic-Interface MIB

RFC1230 PS   May 91     IEEE 802.4 Token Bus MIB

RFC1231 PS   May 91     IEEE 802.5 Token Ring MIB

RFC1233      May 91     Definitions of Managed Objects for the DS3 Interface
                        Type

RFC1232      May 91     Definitions of Managed Objects for the DS1 Interface
                        Type

RFC1238 E    Jun 91     CLNS MIB - for use with Connectionless Network Protocol
                        (ISO 8473) and End System to Intermediate System (ISO
                        9542)

RFC1284 PS   Dec 91     Definitions of Managed Objects for the Ethernet-like
                        Interface Types

RFC1283 E    Dec 91     SNMP over OSI

RFC1298      Feb 92     SNMP over IPX

RFC1304 PS   Feb 92     Definitions of Managed Objects for the SIP Interface
                        Type
SNMP Authentication (snmpauth)

Charter

Chair(s):
     Jeffrey Schiller  <[e-mail]>

Network Management Area Director(s)
     J.R. Davin  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Status: concluded

Description of Working Group:

To define a standard mechanism for authentication within the SNMP.
Goals and Milestones:

   May 90 Write an RFC specifying procedures and formats for providing
          standardized authentication within the SNMP.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  None to date.
SNMP Security (snmpsec)

Charter

Chair(s):
     James Galvin  <[e-mail]>
     Keith McCloghrie  <[e-mail]>

Security Area Director(s)
     Steve Crocker  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           [e-mail]

Description of Working Group:

Enhancements to the SNMP network management framework are being
contemplated within the SNMP Version 2 Working Group of the IETF. The
SNMP Security Working Group is chartered to consider changes to RFCs
1351, 1352, 1353 that may be required either for consistency with this
SNMP evolution effort or to reflect implementation experience with the
current specifications.

Goals and Milestones:

     Done Publish Internet-Draft specifications.

     Done Submit specification to IESG for consideration as a Proposed
          Standard.

     Done At the November IETF meeting, review and discuss feedback from
          implementation experience of the present specifications and
          requirements from the evolution of the SNMP Framework.

     Done Publish updated SNMP Security documents as Internet-Drafts.

   Feb 93 Submit the SNMP Security Documents to the IESG for consideration as a
          Draft Standard.

SNMP Version 2 (snmpv2)

Charter

Chair(s):
     Bob Stewart  <[e-mail]>

Network Management Area Director(s)
     J.R. Davin  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           thumper.bellcore.com:~/pub/davin/snmp2-archive

Description of Working Group:

This Working Group is chartered to consider technical contributions to
the SNMP evolution process and to produce a single recommendation as
to which contributions (or combinations or modifications thereof)
should define the next generation SNMP network management framework.

The announced deadline for technical contributions to the SNMP
evolution process is September 10, 1992. Any individual interested in
contributing to this process should prepare and submit his/her
contribution according to the requirements for detail, completeness,
copyright, and format set forth in the original announcement. This
Working Group is under no obligation to consider contributions that do
not meet these basic requirements or contributions that are not
submitted by the contribution deadline.

This Working Group has the option of (a) rejecting any or all
contributions as the basis for positive evolution, (b) accepting any
or all contributions as candidates for standardization, or (c)
modifying or combining any or all contributions to produce consensus
proposals for standardization.

The product of the Working Group will be a single recommendation to
the IESG identifying those submitted specifications (or modifications
thereof), if any, whose standardization as part of the SNMP framework
is agreed to be warranted and desirable.  The Working Group will not
be chartered to produce tutorial, explanatory, advisory, or
informational documents of any kind.

In its deliberations, the Working Group will take special cognizance
of architectural principles on which the historic success of SNMP has
rested:

(1) The SNMP framework minimizes the overall cost of a manageable
network by minimizing the cost and complexity of those management
system components that are most numerous.

(2) The SNMP framework fosters ubiquity of deployment by admitting the
widest possible range of implementation strategies.

(3) The SNMP framework fosters operational robustness by realizing
management system function as closely as possible to centers of
responsible authority.

(4) The SNMP framework fosters operational robustness by locating
control of resources consumed by the management activity (e.g.,
bandwidth, processing) as closely as possible to centers of
responsible authority.

Moreover, the deliberations of the Working Group will take special
cognizance of at least two aspects of evolutionary logistics:

(1) A single transition from existing SNMP technology to the next
stage of SNMP evolution is highly desirable; multi-stage or protracted
transitions are less desirable.

(2) Minimizing the number of distinct management technologies
concurrently deployed in the Internet is highly desirable.

Consistent with the community desire for timely, deliberate progress,
the Working Group may be disbanded at the time of the IETF plenary
meeting in the Spring of 1993 regardless of whether or not it has
produced the single recommendation required by its Charter.

This Working Group is not chartered to consider security aspects of
the SNMP framework, as these are addressed as a matter of course by an
existing IETF working group.


Goals and Milestones:

     Done Post as an Internet-Draft the technical proposals to the SNMP
          Evolution Working Group.

     Done Closing date for technical proposals.

     Done First Working Group meeting.

     Done Working Group meeting in Washington DC IETF Plenary.

   Mar 93 Working Group meeting at the IETF Plenary.

   Mar 93 Submit a proposal to the IESG for consideration as a Proposed
          Standard.

Internet Security Policy (spwg)

Charter

Chair(s):
     Richard Pethia  <[e-mail]>

Security Area Director(s)
     Steve Crocker  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Status: concluded

Description of Working Group:

The Security Policy Working Group (SPWG) is chartered to create a proposed
Internet Security Policy for review, possible modification, and
possible adoption by the Internet Activities Board.  The SPWG will
focus on both technical and administrative issues related to security,
including integrity, authentication and confidentiality controls, and
the administration of hosts and networks.

Among the issues to be considered in this Working Group are:

\begin{itemize}

\item
   Responsibilities and obligations of users, database
     administrators, host operators, and network managers.

\vspace{.2in}
\item
   Technical controls which provide protection from disruption of
     service, unauthorized modification of data, unauthorized disclosure
     of information and unauthorized use of facilities.

\vspace{.2in}
\item
   Organizational requirements for host, local network, regional
     network and backbone network operators.

\vspace{.2in}
\item
   Incident handling procedures for various Internet components.

\end{itemize}

Goals and Milestones:

     Done Review and approve the Charter making any necessary changes.  Begin
          work on a policy framework.  Assign work on detailing issues for each
          level of the hierarchy with first draft outline.

     Done Revise and approve framework documents.  Begin work on detailing
          areas of concern, technical issues, legal issues, and recommendations
          for each level of the hierarchy.

     Done Prepare first draft policy recommendation for Working Group review
          andmodification.

     Done Finalize draft policy and initiate review following standard RFC
          procedure.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  RFC  Stat Published    Title
------- -- ---------- -----------------------------------------
RFC1281      Nov 91     Guidelines for the Secure Operation of the Internet
Site Security Policy Handbook (ssphwg)

Charter

Chair(s):
     J. Paul Holbrook  <[e-mail]>
     Joyce K. Reynolds  <[e-mail]>

Security Area Director(s)
     Steve Crocker  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Status: concluded

Description of Working Group:

The Site Security Policy Handbook Working Group is chartered to create
a handbook that will help sites develop their own site-specific
policies and procedures to deal with computer security problems and
their prevention.

Among the issues to be considered in this group are:

\begin{enumerate}

\item Establishing official site policy on computer security:

\begin{itemize}

\item       Define authorized access to computing resources.
\item       Define what to do when local users violate the access policy.
\item       Define what to do when local users violate the access policy of
         a remote site.
\item       Define what to do when outsiders violate the access policy.
\item       Define actions to take when unauthorized activity is suspected.
\end{itemize}

\item Establishing procedures to prevent security problems:

\begin{itemize}
\item        System security audits.
\item        Account management procedures.
\item        Password management procedures.
\item        Configuration management procedures.
\end{itemize}

\item Establishing procedures to use when unauthorized activity occurs:

\begin{itemize}
\item        Developing lists of responsibilities and authorities:  site
         management, system administrators, site security personnel,
         response teams.
\item        Establishing contacts with investigative agencies.
\item        Notification of site legal counsel.
\item        Pre-defined actions on specific types of incidents (e.g.,
         monitor activity, shut-down system).
\item        Developing notification lists (who is notified of what).
\end{itemize}

\item Establishing post-incident procedures

\begin{itemize}
\item        Removing vulnerabilities.
\item        Capturing lessons learned.
\item        Upgrading policies and procedures.
\end{itemize}

\end{enumerate}



Goals and Milestones:

     Done Review, amend, and approve the Charter as necessary.  Examine the
          particular customer needs for a handbook and define the scope.
          Continue  work on an outline for the handbook.  Set up an SSPHWG
          ``editorial    board for future writing assignments for the first
          draft of document.

     Done Finalize outline and organization of handbook.  Partition out pieces
          to interested parties and SSPHWG editorial board members.

     Done Pull together a first draft handbook for Working Group review and
          modification.

   Oct 90 Finalize draft handbook and initiate IETF Internet Draft review
          process, to follow with the submission of the handbook to the RFC
          Editor for publication.

   Oct 90 Finalize draft handbook and initiate IETF Internet Draft review
          process, to follow with the submission of the handbook to the RFC
          Editor forpublication.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  RFC  Stat Published    Title
------- -- ---------- -----------------------------------------
RFC1244      Jul 91     Site Security Handbook
Service Location Protocol (svrloc)

Charter

Chair(s):
     John Veizades  <[e-mail]>
     Scott Kaplan  <[e-mail]>

Transport and Services Area Director(s)
     Dave Borman  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           apple.com:~/pub/srv-location/svr-loc-archive

Description of Working Group:

The Service Location Working Group is chartered to investigate
protocols to find and bind to service entities in a distributed internetworked
environment.  Issues that must be addressed are how such a protocol would
interoperate with existing directory based services location protocols.
Protocols that would be designed by this Group would be viewed as an adjunct
to directory service protocols.  These protocols would be able to provide a
bridge between directory services and current schemes for service location.

The nature of the services location problem is investigative in
principle.  There is no mandate that a protocol should be drafted as part
of this process.  It is the mandate of this Group to understand the operation
of services location and then determine the correct action in their view
whether it be to use current protocols to suggest a services location
architecture or to design a new protocol to compliment current architectures.



Goals and Milestones:

     Done  Open discussion and determine if a Working Group should be formed.

     Done Continue discussion trying to refine the problem statement and
          possible resolutions.

   Jul 91 Do we take the RFC track or do we write a report on our conclusion
          and leave it at that?

TCP Large Windows (tcplw)

Charter

Chair(s):
     David Borman  <[e-mail]>

Transport and Services Area Director(s)
     Dave Borman  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The TCP Large Windows Working Group is chartered to produce a
specification for the use of TCP on high delay, high bandwidth paths.
To this end, this Working Group recommended RFC 1072 ``TCP extensions
for long-delay paths'' and RFC 1185 ``TCP Extension for High-Speed
Paths'' be published jointly as a Proposed Standard.  Deficiencies in
the technical details of the documents were identified by the
End-to-End Research Group of the IRTF.  Rather than progress the
standard with known deficiencies, the IESG tasked the End-to-End
Research Group to fix and merge these two documents into a single
protocol specification document. This review was done on the
[e-mail] mailing list.

The TCP Large Windows Working Group is being resurrected for a one
time meeting, to review and if appropriate, approve this new document.


Goals and Milestones:

     Done Review the TCP Extended Window Size proposal from the IRSG End to End
          Research Group and if acceptable, recommend it for standards status.

TELNET (telnet)

Charter

Chair(s):
     Steve Alexander  <[e-mail]>

Applications Area Director(s)
     Russ Hobby  <[e-mail]>
     Erik Huizer  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The TELNET Working Group will examine RFC 854, ``Telnet Protocol
Specification'', in light of the last six years of technical
advancements, and will determine if it is still accurate with how the
TELNET protocol is being used today.  This Group will also look at all
the TELNET options, and decide which are still germane to current day
implementations of the TELNET protocol.


(1) Re-issue RFC 854 to reflect current knowledge and usage of the
    TELNET protocol.

(2) Create RFCs for new TELNET options to clarify or fill in any
    missing voids in the current option set.  Specifically:

    - Environment variable passing
    - Authentication
    - Encryption
    - Compression

(3) Act as a clearing-house for all proposed RFCs that deal with the
    TELNET protocol.



Goals and Milestones:

     Done Write an environment option.

     Done Post an Internet-Draft describing the authentication option.

   Dec 90 Post an Internet-Draft describing the encryption option.

   Mar 91 Rewrite RFC 854.

     Done Submit the authentication option to the IESG as an Experimental
          Protocol.

   Jul 93 Submit the encryption option to the IESG as an Experimental Protocol.

Topology Engineering (tewg)

Charter

Chair(s):
     TBD   <>

Operational Requirements Area Director(s)
     Phill Gross  <[e-mail]>
     Bernard Stockman  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Status: concluded

Description of Working Group:

The Topology Engineering Working Group monitors and coordinates
connections between networks, particularly routing relationships.

\begin{itemize}
\item Monitor interconnectivity among national and international
      backbones and mid-level networks.

\vspace{.2in}
\item Monitor interconnection policies with a view of moving toward a
      common scheme for managing interconnectivity.

\vspace{.2in}
\item Act as a forum where network engineers and representatives of
      groups of networks can come together to coordinate and tune their
      interconnections for better efficiency of the Internet as a whole.

\end{itemize}

Goals and Milestones:

  Ongoing Reports to the Internet community will be given reflecting what we
          learn each quarter.  This periodic report will be of use to the IETF,
          to FARnet, and to the CCIRN members.

   Dec 90 An immediate project is to produce an RFC which will help mid-level
          networks when changing their interconnectivity.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  None to date.
Minimal OSI Upper-Layers (thinosi)

Charter

Chair(s):
     Peter Furniss  <[e-mail]>

Applications Area Director(s)
     Russ Hobby  <[e-mail]>
     Erik Huizer  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           pluto.ulcc.ac.uk:~/ulcc/thinosi

Description of Working Group:

The OSI upper-layer protocols (above Transport) are rich in function
and specified in large, complex and numerous documents. However, in
supporting a particular application, the protocol actually used is only
a subset of the whole. An implementation is not required to support
features it never uses, and it is or should be possible to have
relatively lightweight implementations specialized for a particular
application or group of applications with similar requirements. The
application protocol could be an OSI application-layer standards or a
protocol originally defined for TCP/IP or other environment. It will be
easier to produce such implementations if the necessary protocol is
described concisely in a single document.

An implementation based on this principle, of the mapping of X Window
System protocol over OSI upper-layers exists.

The Working Group is chartered to produce two documents

``Skinny bits for byte-stream'' a specification of the bit (octet)
sequences that implement the OSI upper-layer protocols (Session,
Presentation and ACSE) as needed to support an application that
requires simple connection, and byte-stream read and write. This will
be based on the octet sequences needed to support X. This will not be
expected to be provide a full equivalent of TCP, nor to cover specific
standardized protocols.

``Skinny bits for Directory'' a specification of the bit sequences
needed for the Directory Access Protocol - in the same style as a), but
to include DAP. The level of functionality of this is to be
determined.

An important aspect of the Group's work is find out if it is possible
to produce useful and concise specification of this kind. A  minor part
is to think of better names.

The Group will also encourage the deployment of X/osi implementations
and interworking experiments with it.


Goals and Milestones:

   May 93 Post an Internet-Draft for ``Skinny bits for Byte-Stream''.

   Aug 93 Post an Internet-Draft for ``Skinny Bits for Directory''.

   Dec 93 Submit the ``Skinny Bits for Byte-Stream'' specification to the IESG
          for consideration as a Proposed Standard.

   Mar 94 Submit the ``Skinny Bits for Directory'' specification to the IESG
          for consideration as a Proposed Standard.

Trusted Network File Systems (tnfs)

Charter

Chair(s):
     Fred Glover  <[e-mail]>

Transport and Services Area Director(s)
     Dave Borman  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           [e-mail]

Description of Working Group:

The Trusted Network File  System Working Group is chartered to define
protocol extensions to the Network File System (NFS) Version 2 protocol
which support network file access in a Multilevel Secure (MLS) Internet
environment.  MLS functionality includes Mandatory Access Control (MAC),
Discretionary Access Control (DAC), authentication, auditing, documentation,
and other items as identified in the Trusted Computer System Evaluation
Criteria (TCSEC) and Compartmented Mode Workstation (CMW) documents.

The primary objective of this Working Group is to specify extensions to the
NFS V2 protocol which support network file access between MLS systems.  It
is intended that these extensions should introduce only a minimal impact on
the existing NFS V2 environment, and that unmodified NFS V2 clients and
servers will continue to be fully supported.

Transferring information between MLS systems requires exchanging additional
security information along with the file data.  The general approach to be
used in extending the NFS V2 protocol is to transport additional user context
in the form of an extended NFS UNIX style credential between a Trusted NFS
(TNFS) client and server, and to map that context into the appropriate server
security policies which address file access.  In addition, file security
attributes are to be returned with each TNFS procedure call.  Otherwise,
the NFS V2 protocol remains essentially unchanged.

The Trusted System Interoperability Group (TSIG) has already developed a
specification which defines a set of MLS extensions for NFS V2, and has also
planned for the future integration of Kerberos as the authentication mechanism.
The TNFS Working Group should be able to use the TSIG Trusted NFS document
as a foundation, and to complete the IETF TNFS specification within the
next 3-6 months.


Goals and Milestones:

   Mar 91 Verify the interoperability of TNFS implementations at the 1992 NFS
          Connectathon.

     Done Review and approve  the  TNFS  Working  Group Charter, review revised
          TSIG TNFS Specification, and publish a  proposed  standard  following
          the July meeting.

   Jul 91 Review revised TSIG TNFS Specification.

   Oct 91 Review outstanding comments/issues from mailing list.

   Oct 91 Make any final  revisions  to  TNFS  document based on comments,
          issues, and interoperability testing.

   Nov 91 Publish a  Proposed  Standard  following  the July meeting.

   Mar 92 Request IESG to make the revised  document  a Draft Standard.

Network Training Materials (trainmat)

Charter

Chair(s):
     Ellen Hoffman  <[e-mail]>
     Jill Foster  <[e-mail]>

User Services Area Director(s)
     Joyce Reynolds  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

Widespread familiarity with global network services and competence in
using them brings benefit to individual users, enriches the information
skills and resources of the community and optimises the return in
investment in networked services.

The Network Training Materials Working Group is chartered to enable the
research community to make better use of the networked services.
Towards this end, the Working Group will work to provide a
comprehensive package of ``mix and match'' training materials for the
broad academic community which will: 1) enable user support staff to
train users to use the networked services and 2) provide users with
self-paced learning material.  In the first instance, it will not deal
with operational training.

This Working Group is the IETF component of a joint RARE/IETF group
working on Network Training Materials.

The Working Group will create a catalogue of existing network training
materials (using the TopNode cataloguing fields where appropriate),
identify the gaps in Network Training Materials and work to identify
the problems associated with hands on training workshops using
networked services providing a real service.

Goals and Milestones:

   Mar 93 First Working Group meeting. Review and approve the Charter with a
          review of documents and materials to be written. x

   Jul 93 Post the catalogue of training materials as an Internet-Draft.

   Dec 93 Submit the catalogue of training materials to the IESG for review and
          publication as an informational RFC.

Transmission Mib (transmib)

Charter

Chair(s):
     John Cook  <[e-mail]>

Network Management Area Director(s)
     J.R. Davin  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Status: concluded

Description of Working Group:

The objective of the Transmission Architecture Working Group is to
drive the development, documentation and testing of MIB objects for
the physical and data-link layers of the OSI model.  The Working Group
attempts to consolidate redundant MIB variables from new specifications into a
universal structure.


Goals and Milestones:

  Ongoing Provide a forum for vendors and users of MAC layer communications
          equipment.

  Ongoing Form sub-Working Groups of experts to define object for the following
          at the data-link layer: X.25, Ethernet, Token, FDDI and T1.

     Done Form a core group to evaluate the work of the sub-Working Groups.

  Ongoing Act as a liaison between sub-Working Groups and the network
          management protocol Working Groups, including SNMP, OIM, IEEE 802.1,
          etc.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  None to date.
Token Ring Remote Monitoring (trmon)

Charter

Chair(s):
     Michael Erlinger  <[e-mail]>

Network Management Area Director(s)
     J.R. Davin  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The Token Ring Remote Monitoring MIB Working Group is chartered to
produce a new MIB specification that extends the facilities of the
existing Remote Monitoring (RMON) MIB (RFC 1271) for use in monitoring
IEEE 802.5 Token Ring networks.

The Token Ring RMON MIB extensions will be developed in the same
architectural framework as the existing Ethernet-based RMON MIB.  The
original RMON MIB architecture was designed with the intention of
incorporating MIB extensions devoted to monitoring other network media
types.  This Token Ring activity is the first attempt at such
integration.

In creating the Token Ring Extensions the Working Group will, wherever
possible, conform to terminology and concepts defined by relevant IEEE
standards.  It may be that a MIB devoted to monitoring may need to
expand on the IEEE objects and definitions.  Such modifications will
be accompanied by a detailed rationale.

All work produced by the Token Ring Remote Monitoring Working Group
will be consistent with the existing SNMP network management framework
and standards.


Goals and Milestones:

     Done Discussion and agreement on models and terminology. Comparison of
          RMON architecture and Token Ring requirements. Assign author and
          editor responsibilities.

     Done Working Group meeting at San Diego IETF.

   Mar 92 Post Internet-Draft of the Token Ring Monitoring MIB.

     Done Working Group meeting at Cambridge IETF.

   Nov 92 Submit the Token Ring MIB to the IESG as a Proposed Standard.

DS1/DS3 MIB (trunkmib)

Charter

Chair(s):
     Tracy Cox  <[e-mail]>
     Fred Baker  <[e-mail]>

Network Management Area Director(s)
     J.R. Davin  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

This Working Group will consider revisions to the DS1 and DS3 MIBs
(currently published as Proposed Standards in RFC 1232 and RFC 1233) in
preparation for their consideration as Draft Standards.

Consistent with the IETF standards process, the Working Group is
chartered to consider only those changes to the DS1 and DS3 MIBs that
are based on implementation experience or on the need to align with
relevant ANSI T1M1 standards. In this context, the Working Group will
thoroughly document the implementation or alignment rationale for each
considered change.

All changes made by the Working Group will be consistent with the
existing SNMP framework and standards --- in particular, those
provisions of RFC 1155 regarding addition and deprecation of objects
in standard SNMP MIBs.

This Working Group will be a short-lived activity, involving a single
meeting, and will conclude its business no later than June 1992.

Goals and Milestones:

     Done Post a draft version of the new DS1 MIB to the Internet-Drafts
          Directory.

     Done Post a revised version of the DS3 MIB to the Internet-Drafts
          Directory.

     Done Submit the DS1 document for the Network Management Directorate
          Review.

     Done Submit the DS3 MIB to the Network Management Directorate for review.

     Done Submit the DS1 MIB to the IESG for Draft Standard Status.

     Done Submit the DS3 MIB to the IESG for approval as a Draft Standard.

TCP/UDP over CLNP-addressed Networks (tuba)

Charter

Chair(s):
     Mark Knopper  <[e-mail]>
     Peter Ford  <[e-mail]>

Internet Area Director(s)
     Philip Almquist  <[e-mail]>
     Stev Knowles  <[e-mail]>
     Dave Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The TUBA Working Group will work on extending the Internet Protocol
suite and architecture by increasing the number of end systems which
can be effectively addressed and routed.  The TUBA effort will expand
the ability to route Internet packets by using addresses which support
more hierarchy than the current Internet Protocol (IP) address space.
TUBA specifies the continued use of Internet Transport Protocols, in
particular TCP and UDP, but encapsulated in ISO 8473 (CLNP) packets.
This will allow the continued use of Internet application protocols
such as FTP, SMTP, Telnet, etc. An enhancement to the current system
is mandatory due to the limitations of the current 32 bit IP
addresses.  TUBA seeks to upgrade the current system by a transition
from the use of the Internet Protocol version 4 to ISO/IEC 8473 (CLNP)
and the corresponding large Network Service Access Point address
space.


In addition to protocol layering issues and ``proof of concept'' work,
the TUBA approach will place significant emphasis on the engineering
and operational requirements of a large, global, multilateral public
data network.  TUBA will work to maximize interoperatability with the
routing and addressing architecture of the global CLNP infrastructure.
The TUBA Working Group will work closely with the IETF NOOP and
IPRP-for-IP Working Groups to coordinate a viable CLNP based Internet
which supports the applications which Internet users depend on such as
Telnet, FTP, SMTP, NFS, X, etc.  The TUBA Working Group will also work
collaboratively with communities which are also using the CLNP
protocol, and will consider issues such as interoperability,
applications coexisting on top of multiple transports, and the
evolution of global public connectionless datagram networks, network
management and instrumentation using CLNP and TUBA, and impact on
routing architecture and protocols given the TUBA transition.

The TUBA Working Group will consider how the TUBA scheme will support
transition from the current IP address space to the future NSAP
address space without discontinuity of service, although different
manufacturers, service providers, and sites will make the transition
at different times. In particular, the way in which implementations
relying on current 32 bit IP addresses will migrate must be
considered.  TUBA will ensure that IP addresses can be assigned, for
as long as they are used, independently of geographical and routing
considerations. One option is to embed IP addresses in NSAP addresses,
possibly as the NSAP end-system identifier. Whatever scheme is chosen
must run in a majority of *-GOSIPs and other NSAP spaces. The TUBA
strategy will require a new mapping in the DNS from NAMEs to NSAP
addresses.

The rationale RFC (RFC-1347) documents issues of transition and
coexistence, among unmodified ``IP'' hosts and hosts which support
``TUBA'' hosts.  Hosts wishing full Internet connectivity will need to
support TUBA.


Goals and Milestones:

     Done Post Initial TUBA rational and discussion as an RFC. (RFC 1347)

     Done Post the Initial TUBA DNS specification. (RFC 1348)

     Done Review and approve the Charter.

     Done Post the TUBA CLNP profile as an Internet-Draft.

     Done Post an Routing and Addressing specification as an Internet-Draft,
          coordinated with the Network OSI Operations Working Group and the
          IDRP for IP Working Group.

   Nov 92 Post a summary report on TUBA deployment in the Internet.

     Done Present the results of Working Group deliberations at the November
          IETF meeting.

   Nov 92 Post an Internet-Draft on the changes required to Internet
          applications affected by the deployment of TUBA.

   Nov 92 Post an Internet-Draft covering the methodologies, instrumentation,
          address administration, routing coordination and related topics.

   Nov 92 Post as an Internet-Draft a revision to RFC 1347 reflecting lessons
          learned in the Working Group deliberation.

User Connectivity (ucp)

Charter

Chair(s):
     Dan Long  <[e-mail]>

Operational Requirements Area Director(s)
     Phill Gross  <[e-mail]>
     Bernard Stockman  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The User Connectivity Working Group will study the problem of how to
solve network users' end-to-end connectivity problems.

Goals and Milestones:

     Done Define the issues that must be considered in establishing a reliable
          service to users of the Internet who are experiencing connectivity
          problems.

          Write a document, addressing the above issues, which describes a
          workable mechanism for solving User Connectivity Problems.  Address
          the above issues.  Submit this document into the RFC pipeline as
          appropriate.

Uninterruptible Power Supply (upsmib)

Charter

Chair(s):
     Jeff Case  <[e-mail]>

Network Management Area Director(s)
     J.R. Davin  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ucs.utk.edu:~/pub/ups-mib/mail-archive

Description of Working Group:

This Working Group will produce a document that defines MIB objects
for use in monitoring and (possibly) control of both high-end and
low-end UPSs and related systems (e.g., power distribution systems or
power conditioning systems). Related devices may be addressed in
this effort to the extent that the primary focus on UPSs is not
compromised.

The MIB object definitions produced will be for use by SNMP and will
be consistent with existing SNMP standards and framework.

At its discretion, the Working Group may fulfill its Charter by the
development of distinct MIB definitions for UPS systems of differing
capabilities, but the number of MIB definitions produced by the
Working Group will not exceed two.

At its discretion, the Working Group may produce an additional
document defining traps that support the management of UPSs.

Although the Working Group may choose to solicit input or expertise
from other relevant standards bodies, no extant standards efforts or
authorities are known with which alignment of this work is required.

Because the structure of UPS implementations varies widely, the
working group shall take special care that its definitions reflect a
generic and consistent architectural model of UPS management rather
than the structure of particular UPS implementations.


Goals and Milestones:

     Done Hold Interim Working Group meeting to review draft.

     Done Post initial draft MIB to Internet-Drafts.

   Mar 93 Meet at March IETF meeting to reach closure on MIB document.

   Apr 93 Submit the UPS MIB to the IESG for consideration as a Proposed
          Standard.

Uniform Resource Identifiers (uri)

Charter

Chair(s):
     Jim Fullton  <[e-mail]>
     Alan Emtage  <[e-mail]>

User Services Area Director(s)
     Joyce Reynolds  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           archives.cc.mcgill.ca:~/pub/uri-archive

Description of Working Group:

The Uniform Resource Identifiers Archives Working Group is chartered to
define a set of standards for the encoding of system independent
Resource Location and Identification information for the use of
Internet information services.

This Working Group is expected to produce a set of documents that will
specify standardized representations of Uniform Resource Locators
(URLs) which specify a standardized method for encoding location and
access information across multiple information systems. Such standards
are expected to build upon the document discussed at the UDI BOF
session held during the 24th IETF meeting in Boston, Unique Resource
Serial Numbers (URSNs) which specify a standardized method for encoding
unique resource identification information for Internet resources and
Uniform Resource Identifiers (URIs), which specify a standardized
method for encoding combined resource identification and location
information systems to be used for resource discovery and access
systems in an Internet environment.

Such a set of standards will provide a framework that: allows the
Internet user to specify the location and access information for files
and other resources on the Internet, allows users and network-based
tools to uniquely identify specific resources on the Internet, and
allows the creation and operation of resource discovery and access
systems for the Internet.  The security of such resource discovery
services will also be considered to be an integral part of the work
of this Group.


Goals and Milestones:

     Done Review and approve the Charter making any changes deemed necessary.
          Examine the scope of the recommended documents. Review the first
          draft of a proposal for Uniform Resource Locators already available.

   Mar 93 Submit URL document as an Internet-Draft.  Review additional draft
          documents and determine necessary revisions.  Follow up discussion
          will occur on mailing list.

   Nov 93 Submit the URL document to the IESG for publication as a Proposed
          Standard RFC.

User Documents (userdoc)

Charter

Chair(s):
     Ellen Hoffman  <[e-mail]>
     Lenore Jackson  <[e-mail]>

User Services Area Director(s)
     Joyce Reynolds  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Status: concluded

Description of Working Group:

The USER-DOC Working Group will prepare a bibliography of on-line and
hard copy documents/reference materials/training tools addressing
general networking information and ``how to use the Internet''.
(Target audience: those individuals who provide services to end users
and end users themselves.)

\begin{itemize}
\item
   Identify and categorize useful documents/reference
     materials/training tools.
\item
   Publish both an on-line and hard copy of this bibliography.
\item
   Develop and implement procedures to maintain and update the
     bibliography.  Identify the organization or individual(s) who will accept
     responsibility for this effort.
\item
   As a part of the update process, identify new materials for
     inclusion into the active bibliography.
\item
   Set up procedures for periodic review of the bibliograhy by USWG.

\end{itemize}


Goals and Milestones:

     Done Format for the bibliography will be decided as well as identification
          of ``sources of information'' (e.g., individuals, mailing lists,
          bulletins, etc.)

     Done Draft bibliography will be prepared

     Done Draft to be reviewed and installed in the Internet-Drafts Directory

     Done Bibliography submitted as an FYI RFC


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  None to date.
User Documents Revisions (userdoc2)

Charter

Chair(s):
     Ellen Hoffman  <[e-mail]>
     Lenore Jackson  <[e-mail]>

User Services Area Director(s)
     Joyce Reynolds  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:


The focus of the USER-DOC2 Working Group is on identifying and locating
documentation about the Internet. A major activity is the revision of
an existing bibliography of on-line and hard copy documents/reference
materials/training tools addressing general networking information and
``How to use the Internet'' (RFC 1175, FYI 3). This effort will also be
used to help locate documentation produced by other organizations and
examine the means by which such documents are made available on the
Internet. The target audience is those individuals who provide services
to end users and end users themselves. The Group is also developing a
new FYI RFC document designed as a very short bibliography targeted at
novice users.

The USER-DOC2 Working Group will:

(1) Identify and categorize useful documents, reference materials,
training tools, and other publications about the Internet, particularly
those available on-line.

(2) Publish on-line and hard copies of the bibliography(s) produced and
other reference material on documentation as needs are identified.

(3) Develop and implement procedures to maintain and update the
bibliography and investigate methods to provide the information in an
on-line format.

(4) As a part of the update process, identify new materials for
inclusion into the active bibliography and identify additional needs
which are required for locating documentation and other publications.

(5) Review procedures for periodic review of the bibliography by the
User Services Working Group.

(6) Examine methods for delivering documentation and work with
providers to improve the availability of basic Internet documentation.


Goals and Milestones:

     Done Identify new ``sources of information'' (e.g., individuals, mailing
          lists, bulletins, etc.) Review existing document and obtain comments
          from others in USWG about needed revisions at the San Diego IETF.

     Done Publish Internet-Draft of the short bibliography for novice users.

     Done Submit the revised FYI document to the IESG for publication as an
          RFC.

     Done Post a revised version of FYI3, ``A bibliography of Internetworking
          Information'' as an Internet-Draft.

   Apr 93 Submit the revised FYI3 to the IESG for publication as an
          Informational RFC.

Internet User Glossary (userglos)

Charter

Chair(s):
     Tracy LaQuey Parker  <[e-mail]>
     Gary Malkin  <[e-mail]>

User Services Area Director(s)
     Joyce Reynolds  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           xylogics.com:gmalkin/usergloss/usergloss-arc

Status: concluded

Description of Working Group:

The Internet User Glossary Working Group is chartered to create
an Internet glossary of networking terms and acronyms
for the Internet community.


Goals and Milestones:

     Done Review Internet user needs and format for a glossary. Discussion of
          current ideas about the glossary and the outline development.
          Finalize outline and organization of the glossary.

     Done Draft of glossary will be prepared, draft to be reviewed and
          modified.

          Second pass draft of glossary. Draft to be reviewed and modified,
          finalize draft glossary.

          Initiate IETF Internet-Draft review process by submission of Userglos
          draft to IETF Secretary.  Follow-up with the submission of the
          glossary to RFC Editor as an FYI RFC.

     Done Examine the particular Internet user needs for a glossary and define
          the scope. Review, amend, and approve the Charter as necessary.
          Discussion of Userglos Working Group Chair nominations submitted by
          USWGers.


Internet-Drafts:

  No Current Internet drafts.

RFC's:

  RFC  Stat Published    Title
------- -- ---------- -----------------------------------------
RFC1392      Jan 93     Internet Users' Glossary
User Services (uswg)

Charter

Chair(s):
     Joyce K. Reynolds  <[e-mail]>

User Services Area Director(s)
     Joyce Reynolds  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           nnsc.nsf.net:~/nsfnet/us-wg*

Description of Working Group:

The User Services Working Group provides a regular forum for people
interested in user services to identify and initiate projects designed
to improve the quality of information available to end-users of the
Internet.  (Note that the actual projects themselves will be handled
by separate groups, such as IETF working groups created to perform certain
projects, or outside organizations such as SIGUCCS.

(1) Meet on a regular basis to consider projects designed to improve services
    to end-users.  In general, projects should:

       - Clearly address user assistance needs;
       - Produce an end-result (e.g., a document, a program plan, etc.);
       - Have a reasonably clear approach to achieving the end-result
         (with an estimated time for completion);
       - Not duplicate existing or previous efforts.

(2) Create working groups or other focus groups to carry out projects deemed
    worthy of pursuing.

(3) Provide a forum in which user services providers can discuss and identify
    common concerns.

Goals and Milestones:

  Ongoing This is an oversight group with continuing responsibilities.

Whois and Network Information Lookup Service (wnils)

Charter

Chair(s):
     Joan Gargano  <[e-mail]>

User Services Area Director(s)
     Joyce Reynolds  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ucdavis.edu:~/pub/ietf-wnils-archive

Description of Working Group:

The Network Information Center (NIC) maintains the central NICNAME
database and server, defined in RFC 954, providing online look-up of
individuals, network organizations, key nodes, and other information
of interest to those who use the Internet.  Other distributed
directory information servers and information retrieval tools have
been developed and it is anticipated more will be created.  Many sites
now maintain local directory servers with information about
individuals, departments and services at that specific site.
Typically these directory servers are network accessible.  Because
these servers are local, there are now wide variations in the type of
data stored, access methods, search schemes, and user interfaces.  The
purpose of the Whois and Network Information Lookup Service (WNILS)
Working Group is to expand and define the standard for WHOIS services,
to resolve issues associated with the variations in access and to
promote a consistent and predictable service across the network.

Goals and Milestones:

     Done Review and approve the Charter making any changes deemed necessary.
          Examine the particular functional needs for expanded whois directory
          service. Begin work on a framework for recommendations.  Assign
          writing assignments for first draft of document.

     Done Post the Whois and Network Information Lookup Service Recommendations
          document as an Internet-Draft.

   Dec 92 Submit the Whois and Network Information Lookup Service
          Recommendations document to the IESG as an Informational document.

   Dec 92 Post a revised WHOIS protocols specification as an Internet-Draft.

   Dec 92 Submit the revised WHOIS protocol documents to the IESG as Draft
          Standards.

X.25 Management Information Base (x25mib)

Charter

Chair(s):
     Dean Throop  <[e-mail]>

Network Management Area Director(s)
     J.R. Davin  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           dg-rtp.dg.com:~/x25mib/Current.Mail

Description of Working Group:

This Working Group will produce a set of three documents that describe
the Management Information Base for X.25.  The first document will
specify the objects for the X.25 Link Layer. The second document will
specify the objects for the X.25 Packet Layer.  The third document will
specify the objects for managing IP over X.25.  The Working Group need
not consider the Physical Layer because the ``Definition of Managed
Objects for RS-232-like Hardware Devices'' already defines sufficient
objects for the Physical Layer of a traditional X.25 stack.  Any
changes needed at the Physical Layer will be addressed as part of that
activity.

The X.25 object definitions will be based on ISO documents 7776 and
8208 however nothing should preclude their use on other similar or
interoperable protocols (i.e., implementations based on CCITT
specifications).

The objects in the Link and Packet Layer documents, along with the
RS-232-like document, should work together to define the objects
necessary to manage a traditional X.25 stack.  These objects will be
independent of any client using the X.25 service.  Both of these
documents assume the interface table as defined in MIB-II contains
entries for the Link and Packet Layer interfaces.  Thus these documents
will define tables of media specific objects which will have a one to
one mapping with interfaces of ifType ddn-x25, rfc877-x25, or lapb.
The objects for the IP to X.25 convergence functions will be defined
analogously with the ipNetToMedia objects in MIB II.

The Working Group will endeavor to make each layer independent from
other layers.  The Link Layer will be independent of any Packet Layer
protocol above it and should be capable of managing an ISO 7776 (or
similar) Link Layer provider serving any client.  Likewise the X.25
Packet Layer objects should be independent of the Link Layer below it
and should be capable of managing an ISO 8208 (or similar) Packet Layer
serving any client.

The Working Group will also produce a third document specifying the
objects for managing IP traffic over X.25.  These objects will reside
in their own table but will be associated with the X.25 interfaces used
by IP.  These objects will not address policy decisions or other
implementation specific operations associated with X.25 connection
management decisions except as explicitly described in existing
standards.  These objects will manage the packet flow between IP and
the X.25 Packet Layer specifically including observation of packet
routing and diagnosis of error conditions.  Progress on the Link and
Packet Layer documents will not depend on progress of the IP over X.25
document.  The IP over X.25 document will proceed on a time available basis after work on the Link and Packet Layer documents and as such the Link and Packet Layers may be completed before the IP over X.25 work.

All documents produced will be for use by SNMP and will be consistent
with other SNMP objects, conventions, and definitions (such as Concise
MIB format).  To the extent feasible, the object definitions will be
consistent with other network management definitions.  In particular
ISO/IEC CD 10733 will be considered when defining the objects for the
X.25 Packet Layer.


Goals and Milestones:

     Done Working Group meeting as part of IETF to review documents.

     Done Distribute first draft of documents and discuss via E-mail.

     Done Distribute updated documents for more E-mail discussion.

     Done Submit the LAPB MIB to the IESG for consideration as a Proposed
          Standard.

     Done Submit the X.25 Packet Layer MIB to the IESG for consideration as a
          Proposed Standard.

   Nov 92 Submit the Multiprotocol over X.25 MIB to the IESG for consideration
          as a Proposed Standard.

X.400 Operations (x400ops)

Charter

Chair(s):
     Alf Hansen  <[e-mail]>
     Tony Genovese  <[e-mail]>

Applications Area Director(s)
     Russ Hobby  <[e-mail]>
     Erik Huizer  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

X.400 management domains are being deployed today on the Internet. There is a
need for coordination of the various efforts to insure that they can
interoperate and collectively provide an Internet-wide X.400 message transfer
service connected to the existing Internet mail service. The overall goal of
this Group is to insure interoperability between Internet X.400 management
domains and the existing Internet mail service. The specific task of this
Group is to produce a document that specifies the requirements and conventions
of operational Internet PRMDs.


Goals and Milestones:

     Done Initial meeting, produce internal outline.

     Done Working draft, circulate to interested people.

   Jul 91 Internet-Draft available.

   Dec 91 Document ready for publication.